MetOffice / MetOffice/lfric_core
Science components use lfric_apps metadata
- 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.