Use of gungho metadata in science component

[EdHone]

Version

main

Are there any linked Issues or Pull Requests?

No response

What happened?

The compute_latlon routine in sci_geometric_constants_mod module of the science component use the f_lon option from the idealised configuration namelist. This is not present within lfric_core and therefore this routine cannot be used within lfric_core.

Interestingly, the f_lat option is in the base_mesh configuration namelist, so can be used within lfric_core (possibly suggesting the correct solution as well).

Paging Thomas Bendall (@tommbendall), any thoughts?

Relevant log output

[tommbendall]

I can't think of a neat solution to this, but can at least try to explain the problems...

• the longitude and latitude fields are normally calculated from the chi fields, but for idealised modelling these should be set to the namelist f_lon and f_lat variables
• the f_lon and f_lat namelist variables are only used for idealised modelling, so should live in the idealised namelist
• LFRic-Core should have no dependency on LFRic-Apps, and no concept of an idealised namelist

So possible solutions and the problems with these are:

1. Move the longitude and latitude fields into LFRic-Apps runtime constants.

• Problem: all other geometric entities are calculated in sci_geometric_constants_mod in LFRic-Core, so this would separate two core geometric entities from the others

2. Move f_lon into the base_mesh namelist.

• Problem: the f_lon and f_lat options have nothing to do with the mesh, so should really live in the idealised namelist

3. Move the idealised namelist into LFRic-Core.

• Problem: this is a namelist of science options, so is not really appropriate for LFRic-Core

4. Move f_lon and f_lat to idealised namelist, and pass them as arguments to all get_longitude or get_latitude calls.

• Problem: this would be a very large amount of work, and would require many new algorithms to have access to idealised_config_mod. This does not seem like a neat solution when idealised modelling is not the primary use of LFRic-Apps