Replicate COMPUTE_ANNEXED_DOFS in adjoint namelist for PSyKAl lite code

[DrTVockerodtMO]

PR Summary

Sci/Tech Reviewer: @tom-j-h
Code Reviewer: @stevemullerworth

Not a very fun solution... Involves creating a copy of the COMPUTE_ANNEXED_DOFS variable in the PSyclone config file for use in the PSyKAl lite adjoint. Unfortunately this is a pre-requisite for testing the adjoint in parallel, but I am open to other suggestions on how best to do this.

Most of the changes are upgrade macros and configurations, for the core code changes look to the changeset to science/adjoint/source/psy/adj_sci_psykal_builtin_lite_mod.f90.

Issue stfc/PSyclone#2674 is open which details turning the copy routines into built-ins. Closing this issue will remove the need for the adjoint namelist variable as PSyclone should decide the loop stop point automatically based on its configuration.

Test branch: https://github.com/DrTVockerodtMO/lfric_apps/tree/test_psykal_lite_adjoint_fix

• fixes Adjoint PSyKAl-lite iterating into annexed/halo with COMPUTE_ANNEXED_DOFS=false #322

Linked-to

• https://github.com/JCSDA-internal/lfric-jedi/pull/1227

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

Suite Information

Item	Value
Suite Name	test_psykal_lite_adjoint_fix/run2
Suite User	terence.vockerodt
Workflow Start	2026-03-10T10:31:33
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	DrTVockerodtMO/lfric_apps@test_psykal_lite_adjoint_fix	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

[james-bruten-mo]

Hi Terry,

A couple of points for upgrade macro approval.

• The macro should only be added to the metadata section with metadata changes, in this case lfric-adjoint. When the apply_macros script is run it will get copied everywhere that requires it.
• The rose-apps shouldn't be changed in this branch. To test the changes create a test branch and apply the macros there. The example files do need manually updating however.
• You can automate the changing of the configuration generation as part of the macro. It requires a bit of python to sort, but means the new namelist doesn't need manually adding. See the section at https://github.com/MetOffice/lfric_apps/blob/main/applications/gungho_model/rose-meta/lfric-gungho_model/version20_21.py#L41 for an example

[DrTVockerodtMO]

Hi Terry,

A couple of points for upgrade macro approval.

* The macro should only be added to the metadata section with metadata changes, in this case `lfric-adjoint`. When the `apply_macros` script is run it will get copied everywhere that requires it.

* The rose-apps shouldn't be changed in this branch. To test the changes create a test branch and apply the macros there. The example files do need manually updating however.

* You can automate the changing of the configuration generation as part of the macro. It requires a bit of python to sort, but means the new namelist doesn't need manually adding. See the section at https://github.com/MetOffice/lfric_apps/blob/main/applications/gungho_model/rose-meta/lfric-gungho_model/version20_21.py#L41 for an example

Understood, I'll revert those changes, thanks!

[ss421]

@DanStoneMO - I think we need a configuration update for this. Can you take a look? We are still part way through completing the stack and configuration upgrades for 3.1 so we cant merge it until we have that. We should still be able to test it though.

[DrTVockerodtMO]

The macro currently isn't working so we're looking for a fix. The macro itself looks okay but the application of them has a problem it seems.

[DanStoneMO]

Accompanying JEDI-side PR is now up at: https://github.com/JCSDA-internal/lfric-jedi/pull/1227
I'll mark our review as approved soon if there's no concerns from the rest of my team

[tom-j-h]

As I said in my message, I don't think there's a way to get the upgrade macro to set false for adjoint_tests and true otherwise, but maybe CR will be able to help. Aside from that this looks fine. Will be good to tidy up once the PSyClone issue is sorted.

[TeranIvy]

@DrTVockerodtMO, thanks for notifying the TCD Team about the issue. Out of curiosity, do you need this because you need different COMPUTE_ANNEXED_DOFS for different parts of the same PSyclone process on the same file? I'm curious why the option of storing another PSyclone config file and deciding which one to use for what via an environment variable denoting the path to it would be more complicated than this.

[DrTVockerodtMO]

@DrTVockerodtMO, thanks for notifying the TCD Team about the issue. Out of curiosity, do you need this because you need different COMPUTE_ANNEXED_DOFS for different parts of the same PSyclone process on the same file? I'm curious why the option of storing another PSyclone config file and deciding which one to use for what via an environment variable denoting the path to it would be more complicated than this.

It's because the PSy layer is not PSycloned that we need the adjoint configuration variable to mimick what the custom PSyclone config does. This variable must always be in sync with the PSyclone config variable (hence not a pretty solution and definitely a workaround) until stfc/PSyclone#2674 is solved by including an adjoint copy routine built-in.