MetOffice / MetOffice/lfric_core

Science components use lfric_apps metadata

Open
#390 1 comment 0 reactions 1 assignee Claimed by @mo-rickywong View on GitHub
enhancement
Dominant language
Fortran
Stars
26
Forks
73
Avg merge
1d 8h
Merged PRs (30d)
4

Description

### Are there any linked Issues or Pull Requests?

_No response_

### Brief description

Code in the science components are reliant on some lfric_apps metadata such as the idealised namelist and the planet namelist. This is clearly wrong. The solution is to stop using the metadata or to move the metadata to lfric_core.

Going further, it would be better if science components were controlled entirely through subroutine arguments as they are dependent on config_mod modules or on modeldb%config which is not ideal. Note, that some science components are involved in creating singletons (runtime constant fields) and there is some concern that by moving away from being controlled by the configuration, there is a risk that calls from different parts of the model may pass in different configuration options leading to surprising behaviour, because the second call may not return the result expected by the caller.

For a more specific comment about this issue, see:

https://github.com/MetOffice/lfric_apps/pull/418#pullrequestreview-4264323729

And looking, for example, at `sci_geometric_constants_mod.x90` which takes `f_lat` and `f_lon`, this routine is called from multiple places deep in the model, so requiring each of those subroutines to access the configuration may not be the right choice (particularly as the variables are required only for planar meshes, such as SCM configurations, and not for global or LAM configurations).

### Further details of the issue.

_No response_

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.