Remove transport PSyAd code

[DrTVockerodtMO]

PR Summary

Sci/Tech Reviewer: Tom Hill (@tom-j-h)
Code Reviewer: Mike Hobson (@mike-hobson)

Removed the PSyAd patches for the transport adjoints. Unstaged the algebra kernels and test algorithms from being built via PSyAd. Added the transport adjoint kernels and test algorithms as source code in adjoint and adjoint_tests respectively. I have also taken the liberty to make them faster to run by simplifying a lot of the PSyAdisms.

N.B.: Unit testing adjoint kernels is a bit different to usual kernels. There are no pFUnit tests for these kernels because the unit test for them involves testing against the tangent linear source code (i.e.: testing against kernels/algorithms in lfric_core, gungho, linear, etc.). These have been committed onto the branch.

• is related to Convert PSyAd kernels and algorithms into source code - meta issue #330
• fixes Convert transport PSyAd kernels and algorithms into source code #623

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 - wololo_psyad_transport/run5

Suite Information

Item	Value
Suite Name	wololo_psyad_transport/run5
Suite User	terence.vockerodt
Workflow Start	2026-07-21T15:03:42
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.07.1	True
jules	MetOffice/jules@2026.07.1	True
lfric_apps	DrTVockerodtMO/lfric_apps@convert_psyad_transport	False
lfric_core	MetOffice/lfric_core@2026.07.1	True
moci	MetOffice/moci@2026.07.1	True
SimSys_Scripts	MetOffice/SimSys_Scripts@2026.07.1	True
socrates	MetOffice/socrates@2026.07.1	True
socrates-spectral	MetOffice/socrates-spectral@2026.07.1	True
ukca	MetOffice/ukca@2026.07.1	True

Task Information

✅ succeeded tasks - 1218

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]

I am currently investigating an issue with one of the kernels that was passing during local canned test runs but suddenly started failing on both the local and test-suite...

[DrTVockerodtMO]

I am currently investigating an issue with one of the kernels that was passing during local canned test runs but suddenly started failing on both the local and test-suite...

All better now, I think I must have deleted a line trying to remove white-space (the white-space did get removed at least).

[Tom Hill (tom-j-h)]

Clearly all implemented correctly as tests are passing, and I've checked nothing has been missed (including removing everything that's no longer used). I haven't gone through all of the code in fine detail as the CR will but generally looks like style has been adhered to exactly.

[Erica Neininger (ericaneininger)]

Approved build changes, on behalf of SSD team

[Mike Hobson (mike-hobson)]

I can't see much wrong with the code in these changes. I just have a couple of very minor comments about using parameter statements.

When the kernels in this change were being generated by PSyAd, there was no practical way to unit test them, so the current testing system was introduced. This is great, and we should definitely keep those tests. However, now the kernels are being stored in the repository, they are now suitable for "normal" unit testing. Please add pFUnit-based unit tests for all the new kernels.

[Mike Hobson (mike-hobson)]

v_dot_n appears to be a constant, so it should be declared as a parameter.

[DrTVockerodtMO]

Addressed in 346ecb9.

[Mike Hobson (mike-hobson)]

Again, v_dot_n appears to be a constant, so it should be declared as a parameter.

[DrTVockerodtMO]

Addressed in 346ecb9.

[DrTVockerodtMO]

I can't see much wrong with the code in these changes. I just have a couple of very minor comments about using parameter statements.

When the kernels in this change were being generated by PSyAd, there was no practical way to unit test them, so the current testing system was introduced. This is great, and we should definitely keep those tests. However, now the kernels are being stored in the repository, they are now suitable for "normal" unit testing. Please add pFUnit-based unit tests for all the new kernels.

Thanks Mike. The current testing system was introduced because the test that really matters for the adjoint is that it is the matrix transpose of the tangent linear/forward. Even if we did things using source code all throughout we would have still needed the adjoint_tests app present. We collectively agreed early on that this would be the way to test the adjoint and that unit tests were not needed.

Happy to do the other changes as soon as possible!

[Mike Hobson (mike-hobson)]

Thanks Mike. The current testing system was introduced because the test that really matters for the adjoint is that it is the matrix transpose of the tangent linear/forward. Even if we did things using source code all throughout we would have still needed the adjoint_tests app present. We collectively agreed early on that this would be the way to test the adjoint and that unit tests were not needed.

I am completely happy that your current testing system really matters and I am definitely not asking you to remove it.

Within the LFRic code bases we require kernels to be unit tested, unless you have a very good reason why they cannot be. I'm guessing that your collective agreement to not have unit tests was made because the kernels were generated (and that would be a good reason not to unit test them). Now they are not generated and I can't see a reason not to unit test them.

If you can give me a really good reason why you can't unit test these kernels I'll happily drop the request. Otherwise, please provide unit tests.

[DrTVockerodtMO]

Thanks Mike. The current testing system was introduced because the test that really matters for the adjoint is that it is the matrix transpose of the tangent linear/forward. Even if we did things using source code all throughout we would have still needed the adjoint_tests app present. We collectively agreed early on that this would be the way to test the adjoint and that unit tests were not needed.

I am completely happy that your current testing system really matters and I am definitely not asking you to remove it.

Within the LFRic code bases we require kernels to be unit tested, unless you have a very good reason why they cannot be. I'm guessing that your collective agreement to not have unit tests was made because the kernels were generated (and that would be a good reason not to unit test them). Now they are not generated and I can't see a reason not to unit test them.

If you can give me a really good reason why you can't unit test these kernels I'll happily drop the request. Otherwise, please provide unit tests.

Thank you for the response. Re-reading my comment I clearly didn't go into enough detail, my apologies. I have written a small document regarding the reasoning why we (in my opinion) ought to not do unit testing of the kernels that I will send your way ASAP.

[Matthew Hambley (MatthewHambley)]

Code owner (build system) review: Removing items from existing lists in line with current usage.

[Mike Hobson (mike-hobson)]

UnitTestingAdjoint.docx

Thanks for the document. As I'm responding to items from it, I've attached it, here. I think there may be some misunderstanding about the purpose of unit testing. A number of the reasons you give for not adding unit tests are actually core qualities of this form of testing. For example, unit tests should be "brittle" (there's no point in having a robust unit test that will never fail) and unit tests should always be redundant (if the only place we test some code is a unit test, then we are definitely missing multiple layers of testing).

Whilst test-driven development can be a great way to develop, I accept that here, the process is to create kernels that are the transpose of the linear kernels, not simply kernels that pass a pre-written unit test. However, there are more benefits to unit testing than simply supporting test-driven development.

Unit tests are not tests of the science. They should not be used, for example, to test that an adjoint is the transpose of the linear code. The unit test should have no knowledge of the purpose of the kernel. The code being called should take a minimal set of fixed inputs. The inputs don't even have to be physically sensible (they often are as this is usually easier). The code is exercised using those inputs and the results are checked to make sure the code has behaved as expected. There should be no science here - it is an almost mechanical test.

Bear in mind that even if you don't think unit tests are useful to you, they will be useful to others. For example, a member of the HPC Optimisation team may come across the kernel in a few year's time and think they might have an optimisation. The unit test is the ideal test to run early in the development process to make sure they haven't broken the kernel.

I don't think any of your arguments are the "smoking gun" that would allow me to ignore our coding standards and commit these changes without unit tests, so I still think you need to add unit tests.

For further information, please see the notes on unit testing in our documentation: https://metoffice.github.io/lfric_core/how_to_use_it/testing/unit_testing.html