Lfric2lfric w2

[Juan Manuel Castillo Sanchez (ukmo-juan-castillo)]

PR Summary

Sci/Tech Reviewer: Ricky Wong (@mo-rickywong)
Code Reviewer: mo-marqh

This is relatively simple change to allow lfric2lfric to regrid W2 fields. The accepted procedure to deal with W2 is to convert them to a set of two W3 and one Wtheta fields, process these fields, and then regenerate back a W2 field with the resulting W3 and Wtheta fields.

This changes will make use of the existing subroutines converting W2 to W3,Wtheta fields, and back.

When we merged this code to the trunk, we discovered that the results were not bit-comparable. After some investigation, it was discovered that the subroutines converting from W2 to W3 and the other way round have implicit dependencies on base_mesh, which have to be removed. This will be done as part of this new PR.

The dependency is in the kernel compute_sample_u_ops_code, which is called by interp_w3wth_to_w2_alg.

• linked Lfric2lfric: interpolate W2 fields #238, Remove base_mesh dependencies in compute_sample_u_ops kernel lfric_core#312

• closes lfric2lfric: processing W2 fields #60

• fixes lfric2lfric: processing W2 fields #60

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)

Test Suite Results - lfric_apps - lfric2lfric_W2/run1

Suite Information

Item	Value
Suite Name	lfric2lfric_W2/run1
Suite User	juan.m.castillo
Workflow Start	2026-03-30T20:11:55
Groups Run	all

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	ukmo-juan-castillo/lfric_apps@lfric2lfric_W2	False
lfric_core	ukmo-juan-castillo/lfric_core@fd96921	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

✅ succeeded tasks - 1512

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

[DrTVockerodtMO]

Thanks for the changes. One minor issue regarding consistent style with the rest of the adjoint tests.

[DanStoneMO]

I tried running this against LFRic-JEDI, and the JEDI interface build failed with:
Generation Error: error: expected '5' arguments for the call to kernel 'compute_sample_u_ops_kernel_type' from invoke 'invoke_5' in the algorithm layer but found '7'. Expected '5' standard arguments, '0' stencil arguments, '0' qr_arguments and '0' halo-depth arguments.

From: https://cylchub/services/cylc-review/view/daniel.stone?&suite=mob-develop-next-mobbalt-3&no_fuzzy_time=0&path=log/job/1/build_jelf__exab_gnu/01/job.out

Any ideas what could be causing this? I've not yet ruled out an error on my part, and I will update if that is the case.

[DanStoneMO]

It looks like the build fail is due to the addition of two new arguments (geometry, topology) to the compute_sample_u_ops_kernel_type calls in interpolation_alg_mod and adj_interpolation_alg_mod.

[Juan Manuel Castillo Sanchez (ukmo-juan-castillo)]

It looks like the build fail is due to the addition of two new arguments (geometry, topology) to the compute_sample_u_ops_kernel_type calls in interpolation_alg_mod and adj_interpolation_alg_mod.

Exactly, that is why there is a lfric_core linked PR. This lfric_core PR is the one modifying the kernel that you observed failing.

[DanStoneMO]

Ah, I see the branch for that now. Is there a PR for that one yet?

[Juan Manuel Castillo Sanchez (ukmo-juan-castillo)]

Ah, I see the branch for that now. Is there a PR for that one yet?

Yes, there is a link in the PR description: MetOffice/lfric_core#312. I added a link to the PR in the issue.

[DanStoneMO]

Alright given it another shot and JEDI is all good with this. No linked PR will be needed for lfric-jedi.

[DrTVockerodtMO]

Thanks for making the changes, code owner review passed.

[Lottie Turner (mo-lottieturner)]

What's the advantage of setting pointers and then calling lfric2lfric_map_regrid rather than just doing something like:

call lfric2lfric_map_regrid(u_in_w3_dst, u_in_w3_src)
call lfric2lfric_map_regrid(v_in_w3_dst, v_in_w3_src)
call lfric2lfric_map_regrid(w_in_w3_dst, w_in_w3_src)

[Lottie Turner (mo-lottieturner)]

Same question here as above - what's the advantage of setting pointers here?

[Lottie Turner (mo-lottieturner)]

Hi Juan - the linked section in the PR summary is meant for linked PRs - i.e. PRs in other repositories that need to go on together, rather than related PRs or PRs that need to go on in sequence. Can you move the #238 mention to the "is related to" section, and clarify whether lfric_core#312 is linked, part of a chain, or just related?