Skip to content

Initialise with true gravity#511

Draft
mo-cjsmith wants to merge 22 commits into
MetOffice:mainfrom
mo-cjsmith:reset_gravity
Draft

Initialise with true gravity#511
mo-cjsmith wants to merge 22 commits into
MetOffice:mainfrom
mo-cjsmith:reset_gravity

Conversation

@mo-cjsmith
Copy link
Copy Markdown

@mo-cjsmith mo-cjsmith commented May 20, 2026

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 existing code to do this has a known defect, which is to be corrected here. An additional variation of this method is added, along with the option to use a method that takes another approach to the problem.

== 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, regravitate, which selects the method to be used for recalculating theta when switching from constant to height-varying gravity.
map_fd_to_prognostics_alg_mod.x90: Place where regravitate is used.

== New Code ==

initialisation/regrav_isotherm_kernel_mod.F90:

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 - test_reset_gravity/run2

Suite Information

Item Value
Suite Name test_reset_gravity/run2
Suite User chris.smith
Workflow Start 2026-05-20T13:14:06
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@test_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

@github-actions github-actions Bot added the cla-required The CLA has not yet been signed by the author of this PR - added by GA label May 20, 2026
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

=Used when the shallow switch is false and reading a start dump
=that has been created by a constant gravity model, such as the UM.
=All methods calculate an Exner field in hydrostatic balance with
=height-varying gravity. This is done by upward integr
Copy link
Copy Markdown
Contributor

@tommbendall Thomas Bendall (tommbendall) May 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -3247,23 +3221,39 @@ help=Horizontal winds are read in on a W2h space from a start dump. If
sort-key=02b
type=logical

[namelist:initialization=regravitate]
compulsory=true
description=Method for switching gravity
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

=that has been created by a constant gravity model, such as the UM.
=All methods calculate an Exner field in hydrostatic balance with
=height-varying gravity. This is done by upward integr
=Isothermodynamic: Preserve absolute temperature and pressure on
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

! under which the code may be used.
!-----------------------------------------------------------------------------

!> @brief Need to say something here
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you might have forgotten to fill these in!

end do

! Map temperature from newly computed grid back onto current model grid
call interp( nlayers+1, ht_wt, th, nlayers+1, height_wth(map_wt(1)), &
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


! Map temperature from newly computed grid back onto current model grid
call interp( nlayers+1, ht_wt, th, nlayers+1, height_wth(map_wt(1)), &
temperature(map_wt(1)) )
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


end subroutine interp

! Does the input UM data, T(z), pi(z), have the correct z information?
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking whether you intended to leave this comment in there?

! Geopotential height
do k = 0, nlayers
ht_wt(k) = planet_radius * height_wth(map_wt(1)+k) / &
( planet_radius - height_wth(map_wt(1)+k) )
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

weight1 = height_w3( map_w3(1) ) - height_wth( map_wt(1) )
exner_surf = exner( map_w3(1) ) * ( cp * temp_virt ) / &
( cp * temp_virt - ( gravity - coriolis_term( map_wt(1) ) ) * weight1 )
theta( map_wt(1) ) = temperature( map_wt(1) ) / exner_surf
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused at the surface theta being updated but no other values. Should theta actually be passed into this kernel?

call invoke( &

select case( regravitate )
case( regravitate_isotherm1 )
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@github-actions github-actions Bot added cla-signed The CLA has been signed as part of this PR - added by GA and removed cla-required The CLA has not yet been signed by the author of this PR - added by GA labels May 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed The CLA has been signed as part of this PR - added by GA

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants