Soil levels in LFRic2UM

[Lottie Turner (mo-lottieturner)]

PR Summary

Sci/Tech Reviewer: Adrian Lock (@Adrian-Lock)
Code Reviewer: svadams (@svadams)

This PR adds the functionality to handle soil multidata fields in LFRic2UM (and also sets up some of the infrastructure to handle the other kinds of multidata/pseudolevel fields). This will add new lfricinputs kgos

• sub-issue of LFRic2UM pseudo-levels #265
• blocks Multidata fields/pseudo-levels in LFRic2UM #266
• is blocked-by Tidying up lfricinputs #434
• is related to LFRic2UM Land-Sea Mask #445 - land sea maskinng

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 - t435_lfric2um_soil_levels/run10

Suite Information

Item	Value
Suite Name	t435_lfric2um_soil_levels/run10
Suite User	charlotte.turner
Workflow Start	2026-04-16T16:29:57
Groups Run	lfric2um', 'developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	mo-lottieturner/lfric_apps@lfric2um_soil_levels	False
lfric_core	MetOffice/lfric_core@018e40c	True
moci	MetOffice/moci@2026.03.2	True
SimSys_Scripts	MetOffice/SimSys_Scripts@4387949	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

❌ failed tasks - 5

Task	State
config_dump_checker	failed
rose_ana_lfricinputs_lfric2um-pseudolevels-C48L70_N48L70_azspice_gnu_fast-debug-64bit	failed
rose_ana_lfricinputs_lfric2um-pseudolevels-C48L70_N48L70_azspice_gnu_full-debug-64bit	failed
rose_ana_lfricinputs_lfric2um-pseudolevels-C48L70_N48L70_ex1a_gnu_fast-debug-64bit	failed
rose_ana_lfricinputs_lfric2um-pseudolevels-C48L70_N48L70_ex1a_gnu_full-debug-64bit	failed

✅ succeeded tasks - 1193

⌛ waiting tasks - 2

Task	State
housekeep_azspice	waiting
housekeep_ex1a	waiting

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

[Adrian Lock (Adrian-Lock)]

An extra "in" that isn't needed:

Suggested change

	! that is currently hardcoded in elsewhere in lfric2um. If at some point that
	! that is currently hardcoded **in** elsewhere in lfric2um. If at some point that

[Adrian Lock (Adrian-Lock)]

And if you did know where it is hardcoded "elsewhere", it would be helpful to say, as increasing soil level number is on a long-term development list and we look to be building up some technical debt in this regard

[Lottie Turner (mo-lottieturner)]

I think the two ins is technically correct - it is [hardcoded in] elsewhere in lfric2um - but it does read better with one in. I'll change that. The hardcoding is in lfric2um_initialise_um_mod.f90, but I think this could easily be changed to be read in from the rose-app.conf file - #266 adds a couple of other variables being read in from there, so could easily do that there (or split that change into another ticket, more likely).

If there was another scheme added, how would they be told apart from the raw file? As in, would it still use the vertical coord type code 6, or would it have its own? If still using 6, would the only difference be the number of layers? or would there be a different flag somewhere?

[Adrian Lock (Adrian-Lock)]

Just wondering if this list might be better in numerical order? Or perhaps group the stash on soil levels separately? The order currently seems arbitrary?

[Lottie Turner (mo-lottieturner)]

The order corresponds to the order of the fields in the iodef.xml file - which is probably somewhat arbitrary in itself, but the easiest way to make the stashcodes human readable and check you're not missing any is to get them to follow the same order as that (2,3,150 are east, north and upward winds, so it makes logical sense to have them grouped together, despite the numbers being different)

[Lottie Turner (mo-lottieturner)]

also the rose config-dump checker doesn't allow you to have separate lines for separate sections, unfortunately, otherwise I'd have done that. Feel free to have a look at the iodef file and suggest a more logical order for those fields though!