Lfric2lfric read order

[ukmo-juan-castillo]

PR Summary

Sci/Tech Reviewer: @stevemullerworth
Code Reviewer:

There are just two simple changes to make things work in lfric2lfric:

1. Call the 'advance' subroutine in he destination xios context after context initialisation when generating restart dumps. This is needed, otherwisethe output file can not be written. It is not done when writing lbc files in order to have the right times in the output files.
2. Substitute the subroutines 'write_checkpoint' and 'read_checkpoint' by 'write_state' and 'read_state'. With the later subroutines the fields are read and stored in memory in the order lfric2lfric expects, and are written in the same format as the input.

• closes lfric2lfric: write restart dump and read input fields in the right order #273
• fixes lfric2lfric: write restart dump and read input fields in the right order #273

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)

The new code changes KGOs, given that multidata fields and multilevel fields that are stored a 2D vectors in the input files are now properly processed. Note that only the regional tests change, as the input data for running global tests just contain 1D fields without multidata. In the KGO files that change, only changes in relevant fields are present, as expected. I will provide some plots below demonstrating that the code works.

trac.log

Test Suite Results - lfric_apps - lfric2lfric_read_order/run1

Suite Information

Item	Value
Suite Name	lfric2lfric_read_order/run1
Suite User	juan.m.castillo
Workflow Start	2026-02-20T08:53:03
Groups Run	all

Dependency	Reference	Main Like
casim	MetOffice/casim@2025.12.1	True
jules	MetOffice/jules@69aaf4d	True
lfric_apps	ukmo-juan-castillo/lfric_apps@lfric2lfric_read_order	False
lfric_core	MetOffice/lfric_core@88533c5	True
moci	MetOffice/moci@2025.12.1	True
SimSys_Scripts	MetOffice/SimSys_Scripts@2025.12.1	True
socrates	MetOffice/socrates@2025.12.1	True
socrates-spectral	MetOffice/socrates-spectral@2025.12.1	True
ukca	MetOffice/ukca@2025.12.1	True

Task Information

❌ failed tasks - 6

Task	State
check_linear_model_nwp_gal9-C12_MG_azspice_gnu_production-32bit	failed
check_linear_model_nwp_gal9-C12_MG_ex1a_cce_fast-debug-32bit	failed
check_linear_model_nwp_gal9-C12_MG_ex1a_cce_production-32bit	failed
check_linear_model_nwp_gal9-C12_MG_ex1a_gnu_fast-debug-32bit	failed
check_linear_model_nwp_gal9-C12_MG_ex1a_gnu_full-debug-32bit	failed
check_linear_model_nwp_gal9-C12_MG_ex1a_gnu_production-32bit	failed

✅ succeeded tasks - 1512

⌛ waiting tasks - 2

Task	State
housekeep_azspice	waiting
housekeep_ex1a	waiting

There are some failing tests, but I believe they fall in the trunk too, given that the changes here should only affect lfric2lfric jobs.

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

[ukmo-juan-castillo]

I add the plots here, all of them in the same order from left to right and top to bottom (always showing the second level or multidata instance): source data in the source mesh; destination field after being interpolated using the weights provided by rose stem, and applied with a python script; destination field generated by lfric2lfric using the 'map' method; destination field generated by lfric2lfric using the 'oasis' method.

theta (multilevel 1D field)

wvar (multilevel 2D field)

canopy_height (multidata 2D field)

For canopy_height, the lfric2lfric method shows something strange on the left of the domain. The problem here is that missing values are not properly understood, and they are processed. Instead of having default zero values for fill values, we have large negative values.

[stevemullerworth]

This PR looks totally fine, and the plots are good evidence that things are working as expected (as compared with the plots in #201 at #201 (comment))

I would like to ask a couple of questions before we go to code review:

1. Are these plots from this branch, or from a #201 branch that includes this fix?
2. Why wasn't the issue spotted when #55 went on? Was it because there was no testing of multidata or 3D fields on trunk then?

[ukmo-juan-castillo]

This PR looks totally fine, and the plots are good evidence that things are working as expected (as compared with the plots in #201 at #201 (comment))

I would like to ask a couple of questions before we go to code review:

1. Are these plots from this branch, or from a #201 branch that includes this fix?

2. Why wasn't the issue spotted when #55 went on? Was it because there was no testing of multidata or 3D fields on trunk then?

These plots are from the output created by this branch. Once this branch and the code in #201 are together, I would also like to plot the results using more than one CPU and compare (unless you want to merge this PR and #201 in one single PR).

The issue that the restart dump was not written was not spotted in #55 because checksums were still being generated and were OK, and we were concentrated in the LBC output not the ICs output. We did not realise that the output was not right because until we started working on #201 we were just plotting the fields theta, zh, and rho, which were not multidata or multilevel 2D, and therefore were processed properly.

[stevemullerworth]

Thanks. SR approved