Stochastic Physics Fixes

[tommbendall]

PR Summary

Sci/Tech Reviewer: @mo-claudiosanchez
Code Reviewer: @cameronbateman-mo

This ticket applies a handful of simple fixes to issues in stochastic physics:

1. It picks up the fixed Wtheta -> W0 kernel from: Fix averaging kernel used in stochastic physics filter lfric_core#222
2. Ensures that the forcing pattern is applied appropriately at W3 and Wtheta points, by passing a new level_offset argument to stph_fp_main_alg
3. Normalises the shifted on wavenumbers in the same way as the comparative UM code: https://github.com/MetOffice/um/blob/main/src/atmosphere/stochastic_physics/stph_skeb2-stph_skeb2.F90#L1341

• linked to Fix averaging kernel used in stochastic physics filter lfric_core#222

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 Core rose-stem suite
• If required (e.g. API changes) I have also run the LFRic Apps test suite using this branch
• 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 - stoch_phys_fixes/run4

Suite Information

Item	Value
Suite Name	stoch_phys_fixes/run4
Suite User	thomas.bendall
Workflow Start	2026-01-16T13:37:13
Groups Run	all

Dependency	Reference	Main Like
casim	MetOffice/[email protected]	True
jules	MetOffice/[email protected]	True
lfric_apps	tommbendall/lfric_apps@TBendall/StochPhysFixes	False
lfric_core	tommbendall/lfric_core@TBendall/FixW0WthFilter	True
moci	MetOffice/[email protected]	True
SimSys_Scripts	MetOffice/[email protected]	True
socrates	MetOffice/[email protected]	True
socrates-spectral	MetOffice/[email protected]	True
ukca	MetOffice/[email protected]	True

Task Information

✅ succeeded tasks - 1456

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

[mo-claudiosanchez]

Hi Tom,

I have started to try to find my way about reviewing the LFRIC ticket. I have got some preliminary questions:

1. Do we have a diagram of LFRIC staggered vertical grid to understand why SKEB levels need to be subtracted by one and added the offset for the vertical phasing?
2. Does the doxygen documentation include variable arguments, if that is the case, does it pick up the change in the "stph_fp_main_alg" argument when including "level_offset"?
3. Which tasks of the all test in ⁠stoch_phys_fixed/run4 include stochastic physics? Is there a twin run without it where timings can be compared?

Thanks!

[tommbendall]

Thanks Claudio. Here are my attempts to answer your questions:

1. Do we have a diagram of LFRIC staggered vertical grid to understand why SKEB levels need to be subtracted by one and added the offset for the vertical phasing?

Good question. I have been back through the UM and LFRic implementations to triple-check this. The context is that SKEB needs the forcing pattern at p-levels while SPT needs it on T-levels.

The UM calculates a psif field on p-levels, which is used in SPT to multiply the theta and moisture increments (which are on T levels). LFRic calculates the forcing pattern separately in W3 (p-levels) and Wtheta (T-levels).

The UM's arrays have a vertical structure in which T-levels are indexed from 0 to N, while p-levels are indexed from 1 to N. Whereas in LFRic, fields are a single 1D array using a Dofmap, and are written to with a pattern like: fp(map(1) + k), where k runs from 0 for both W3 and Wtheta, for instance LFRic computes the forcing pattern field here: https://github.com/MetOffice/lfric_apps/blob/main/interfaces/physics_schemes_interface/source/kernel/stph/spectral_2_cs_kernel_mod.F90#L193

So because this indexing is different, the solution Ian proposed was to offset the forcing pattern used in SKEB (calculated in W3) so that it creates a field matching that in the UM.

2. Does the doxygen documentation include variable arguments, if that is the case, does it pick up the change in the "stph_fp_main_alg" argument when including "level_offset"?

Yes the doxygen documentation will pick up this description of the new argument: https://github.com/MetOffice/lfric_apps/pull/148/changes#diff-15bab3cd211a7d31b56b0fc280bd500d9cc2f6622bb07f31de75a5d503333cebR50

3. Which tasks of the all test in ⁠stoch_phys_fixed/run4 include stochastic physics? Is there a twin run without it where timings can be compared?

All of the run_lfric_atm_clim* tests include stochastic physics -- these are also the tests for which the KGO files have changed. I've done a comparison run at ⁠main_vn3/run1 and also run the weekly lfric_atm suite (which includes tests we typically use to measure performance) at ⁠stoch_phys_fixes/run5. Here is a summary of timings from the C48 climate tests.

Mean time for stph_main_alg in seconds:

Test Case	Main@vn3	stoch_phys_fixes branch
lfric_atm_clim_gal9_1T-C48_MG_ex1a_gnu_fast-debug-32bit (1 thread)	2.22	2.54
lfric_atm_clim_gal9_2T-C48_MG_ex1a_gnu_fast-debug-32bit (2 threads)	4.53	3.88
lfric_atm_clim_gal9_4T-C48_MG_ex1a_gnu_fast-debug-32bit (4 threads)	7.04	7.18
lfric_atm_clim_gal9-C48_MG_ex1a_cce_production-32bit-crun0 (no threading, first crun)	7.74	7.73
lfric_atm_clim_gal9-C48_MG_ex1a_cce_production-32bit-crun1 (no threading, second crun)	7.89	7.89

My interpretation is that the computational impact of the changes in this branch are smaller than general variability for these tests (which is what we expect!)

[mo-claudiosanchez]

Thanks Tom for your detailed explanation! I think I finally understood the need for "level_offset". The UM uses the same defition of "kr" for the vertical phase shifting factor, both defined in eta_theta_levels at SKEB at stph_skeb2-stph_skeb2.F90#L1351 and SPT at for_pattern.F90#L459 and copied below, I would think that it is not very consistent (SKEB should prob. use rho_levels instead of theta_levels).

kr = eta_theta_levels(k) * (r_theta_levels(1,1,tdims%k_end) - planet_radius)/ 12000.0

My original implementation in LFRIC was also applied at theta levels for both, SKEB and SPT, at stph_fp_main_alg_mod.x90#L163, shown below.

kr = (domain_height*eta_theta_levels(k + level_offset))/12.0e3_r_def

Adding the "level_offset" is probably the most efficient solution, although something like the code below may be clearer, and not hugely more expensive (the vertical loop should be less than 50-100 iterations!). Note, the name for "get_level_type" is probably different.

level_type = get_level_type(fp)

if level_type = WTHETA 
   kr ~ theta_levels
elif level_type = W3
   kr ~ rho_levels
end if 

It is probably worth defining the vertical space of SKEB and SPT bottom and upper levels in their help metadata at rose-meta.conf.

[mo-claudiosanchez]

Thanks, I think the extra commented lines explains well the purpose of level_offset. I have no other comments or suggestions, passing the ticket to code 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

[mo-claudiosanchez]

Thanks, the purpose of level_offset is now quite clear thanks to the extra comment lines.
Passing ticket for code review.

[tommbendall]

@oakleybrunt this is ready for code review, but I just wanted to make you aware this is linked to MetOffice/lfric_core#222 which is has been assigned to @cameronbateman-mo

[james-bruten-mo]

@oakleybrunt this is ready for code review, but I just wanted to make you aware this is linked to MetOffice/lfric_core#222 which is has been assigned to @cameronbateman-mo

Sorry Tom, reassigned to Cameron for both now

[cameronbateman-mo]

All looks good, moving to approved.