Initialise with true gravity

[mo-cjsmith]

PR Summary

Sci/Tech Reviewer: Thomas Bendall (@tommbendall)
Code Reviewer:

Although the shallow atmosphere approximation is not used by UM(ENDgame) , it still retains the constant gravity field of earlier models. If LFRic is to run with true height-varying gravity, initialisation from a UM start-dump must take account of the change in gravity between the two models to avoid a significant change to the meteorology of the data. The code to do this hasn't performed as expected. This ticket does the following:

1. Modify diagnostic calculations to be correct for both constant and height-varying gravity.
2. Replace hydro_shallow_to_deep_kernel_mod.F90 with two separate kernels: one for the downwards integration to find Exner with constant gravity; the other to integrate upwards to find Exner with height-varying gravity. The first of these is achieved using the existing hydrostatic_coriolis_kernel_mod.F90 and the latter by a new kernel, regrav_preserve_t_kernel_mod.F90 (perhaps this needs a better name).
3. Introduce an optional stage between the two kernels in step (2), implemented in regrav_geopot_kernel_mod.F90. This makes use of the conjecture that absolute temperature should be the same function of geopotential height for both constant and height-varying gravity. For constant gravity, geopotential height and physical height are the same. This is not the case for height-varying gravity. Consequently interpolation is required to map temperature onto the computational grid.

A significant change comes with the above. In the hydro_shallow_to_deep kernel the downward integration stage used absolute temperature, which was obtained from T=theta*exner using the equation of state to find exner from theta and density information. This differs from how the scheme was originally developed. The changes above return the scheme to its original form, while also introducing the optional interpolation stage.

== Code Changes ==

geo_on_pres_kernel_mod.F90 and pres_lev_diags_alg_mod.x90: Diagnostic of geopotential height on a constant pressure level changed to use the model geopotential, rather than height_w3 field, so that it is valid for shallow=.false. as well as shallow=.true..
rose-meta.conf: New setting in the initialization namelist, regrav_order, which sets the order of interpolation used in step (3) above. Currently the only values available are 0=no interpolation and 1=linear interpolation.
map_fd_to_prognostics_alg_mod.x90: Place from which kernels are called.

== New Code ==

initialisation/regrav_preserve_t_kernel_mod.F90: Finds Exner by upward integration of hydrostatic balance, formulated with absolute temperature.

initialisation/regrav_geopot_kernel_mod.F90: Interpolates temperature onto the grid from locations associated with given geopotential heights.

Code Quality Checklist

• I have performed a self-review of my own code
• My code follows the project's style guidelines
• Comments have been included that aid understanding and enhance the readability of the code
• My changes generate no new warnings
• All automated checks in the CI pipeline have completed successfully

Testing

• I have tested this change locally, using the LFRic Apps rose-stem suite
• If any tests fail (rose-stem or CI) the reason is understood and acceptable (e.g. kgo changes)
• I have added tests to cover new functionality as appropriate (e.g. system tests, unit tests, etc.)
• Any new tests have been assigned an appropriate amount of compute resource and have been allocated to an appropriate testing group (i.e. the developer tests are for jobs which use a small amount of compute resource and complete in a matter of minutes)

trac.log

Test Suite Results - lfric_apps - test2_reset_gravity/run6

Suite Information

Item	Value
Suite Name	test2_reset_gravity/run6
Suite User	chris.smith
Workflow Start	2026-06-15T13:43:08
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	mo-cjsmith/lfric_apps@test2_reset_gravity	False
lfric_core	MetOffice/lfric_core@2026.03.2	True
moci	MetOffice/moci@2026.03.2	True
SimSys_Scripts	MetOffice/SimSys_Scripts@2026.03.2	True
socrates	MetOffice/socrates@2026.03.2	True
socrates-spectral	MetOffice/socrates-spectral@2026.03.2	True
ukca	MetOffice/ukca@2026.03.2	True

Task Information

✅ succeeded tasks - 1164

Security Considerations

• I have reviewed my changes for potential security issues
• Sensitive data is properly handled (if applicable)
• Authentication and authorisation are properly implemented (if applicable)

Performance Impact

• Performance of the code has been considered and, if applicable, suitable performance measurements have been conducted

AI Assistance and Attribution

• Some of the content of this change has been produced with the assistance of Generative AI tool name (e.g., Met Office Github Copilot Enterprise, Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the Simulation Systems AI policy (including attribution labels)

Documentation

• Where appropriate I have updated documentation related to this change and confirmed that it builds correctly

PSyclone Approval

• If you have edited any PSyclone-related code (e.g. PSyKAl-lite, Kernel interface, optimisation scripts, LFRic data structure code) then please contact the TCD Team

Sci/Tech Review

• I understand this area of code and the changes being added
• The proposed changes correspond to the pull request description
• Documentation is sufficient (do documentation papers need updating)
• Sufficient testing has been completed

(Please alert the code reviewer via a tag when you have approved the SR)

Code Review

• All dependencies have been resolved
• Related Issues have been properly linked and addressed
• CLA compliance has been confirmed
• Code quality standards have been met
• Tests are adequate and have passed
• Documentation is complete and accurate
• Security considerations have been addressed
• Performance impact is acceptable

[Thomas Bendall (tommbendall)]

Thanks Chris, sorry if I've jumped the gun here with a review since the PR is still in "draft" state. I'm really excited about this potentially facilitating the use deep gravity.

Along with some minor in-line comments, I have two major suggestions:

1. Do we need to still include all of the different isotherm* options? I don't think any of the isotherm* options are tested, and since the geopot option seems to perform best, should we remove all of the isotherm* options? Or possibly keep only one that preserves the old behaviour?

2. Do we need unit-tests for the new kernels?

[Thomas Bendall (tommbendall)]

there seems to be some of the help section missing here!

[Thomas Bendall (tommbendall)]

Could you make this slightly clearer?

Suggested change

	description=Method for switching gravity
	description=Method for setting up initial hydrostatic balance when using deep gravity but a start dump that assumed shallow gravity

[Thomas Bendall (tommbendall)]

If we're to keep the different isothermal methods (I wonder if we don't!), should we explain the differences between them here?

[Thomas Bendall (tommbendall)]

I think you might have forgotten to fill these in!

[Thomas Bendall (tommbendall)]

I'm a bit confused about this call, based on the interp function, shouldn't this be height_wth(map_wt(1):map_wt(1)+nlayers)?

It looks like we are passing in an element of an array instead of a section of an array

[mo-cjsmith]

I wasn't thinking! It's the whole array that's being passed in any case. It works, though. In Fortran, when one element of an array is in an argument list, it's just the memory address of the start point for part of the array. This avoids the creation and copying to and from a temporary array when a whole slice is put in the argument list. Perhaps this is a bit of an f77 throwback?!

[Thomas Bendall (tommbendall)]

Similarly, I'm a bit confused about this call, based on the interp function, shouldn't this be temperature(map_wt(1):map_wt(1)+nlayers)?

It looks like we are passing in an element of an array instead of a section of an array

[Thomas Bendall (tommbendall)]

I'm wondering if we should enforce that this calculation is done at double precision, since planet_radius could be very large and height_wth could be very small

[mo-cjsmith]

I tried promoting to double without success. First using r_double then real64. Both caused failures in the developer suite. For Earth and UM grids at least, the loss of accuracy isn't disastrous if no promotion is done. Also, the geopotential is calculated in just the same way elsewhere in the model.

[Thomas Bendall (tommbendall)]

I wonder if we need all of these isotherm methods? Or if you want to preserve the current behaviour, we could just keep your isotherm1 method?

[mo-cjsmith]

There used to be more! But you're right, a further cull is required. I've decided to keep the current scheme as originally intended, though, rather than what actually made it on to trunk. The version on trunk isn't in a rose stem test, so no KGOs are harmed. And we know the trunk version isn't one that we want.

[mo-cjsmith]

Hi Tom,
Thank you for the initial science review. I've made your suggested changes and hopefully it's a bit more coherent for review this time. The PR Summary has been updated and the rose stem developer tests are ok. The web page still says there are code conflicts but I don't know what this means. There doesn't seem to be any problem with the working copy - and I haven't done any merges.

Thanks,

Chris.