[Benjamin Went (MetBenjaminWent)]

We have a number of Transmute PSyclone scripts on trunk, however we have little awareness of when they fail.
We log out when Transformations fail in the scripts, however there is alot of false positives, by design of how the scripts currently work where these 'failures' are as part of how the script functions.
Whilst we need to look at this logging (IE what and when we log, and how we filter out genuine issues), we can also implement something simple which would act as an early warning indicator of an issue with the Transmute scripts on trunk.
This can come about with a change of PSyclone versioning, and due to the above issues, difficult to detect. #630 was prompted by such as issue which was not initially detected when it arose.

This PR contains a new simple test which contains a pattern commonly utilised by the Transmute scripts on example source which requires specific things of the Psyclone transformation in order to be successfully parallelised.
As long as this pattern exists in Transmute, this test should remain as it is.
For example: https://github.com/MetOffice/lfric_apps/blob/main/applications/lfric_atm/optimisation/meto-ex1a/transmute/global.py

Note I've suppressed the PSyclone warnings that we have pulled through as to not clog up the python testing output.
It still fails as expected if the source changes.

PR Summary

Sci/Tech Reviewer: Oakley Brunt (@oakleybrunt)
Code Reviewer: James Bruten (@james-bruten-mo)

Issue: #755
Umbrella: #424

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

Failures are due to issues with AZ and PSyclone, unrelated to these changes.

Test Suite Results - lfric_apps - psyclone-test/run4

Suite Information

Item	Value
Suite Name	psyclone-test/run4
Suite User	benjamin.went
Workflow Start	2026-09-18T10:08:25
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.07.1	True
jules	MetOffice/jules@c22aeea	True
lfric_apps	MetBenjaminWent/lfric_apps@psyclone-test	False
lfric_core	MetOffice/lfric_core@3e965e8	True
moci	MetOffice/moci@2026.07.1	True
SimSys_Scripts	MetOffice/SimSys_Scripts@77a5166	True
socrates	MetOffice/socrates@2026.07.1	True
socrates-spectral	MetOffice/socrates-spectral@2026.07.1	True
ukca	MetOffice/ukca@9fc2b6d	True

Task Information

❌ failed tasks - 3

Task	State
build_linear_model_azspice_gnu_fast-debug-64bit	failed
build_linear_model_azspice_gnu_production-32bit	failed
build_ngarch_azspice_gnu_full-debug-64bit	failed

✅ succeeded tasks - 1181

⌛ waiting tasks - 10

Task	State
run_linear_model_dcmip301-C24_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_dcmip301_ffsl-C24_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_nwp_gal9-C12_MG_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_nwp_gal9-C12_MG_azspice_gnu_production-32bit	waiting
run_linear_model_nwp_gal9_ffsl-C12_MG_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_nwp_gal9_random-C12_MG_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_nwp_gal9_zero-C12_MG_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_runge-kutta-C12_azspice_gnu_fast-debug-64bit	waiting
run_linear_model_semi-implicit-C12_azspice_gnu_fast-debug-64bit	waiting
run_ngarch_default-C24_azspice_gnu_full-debug-64bit	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 HPC Optimisation 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

[Andy Porter (arporter)]

OMPParallelLoopTrans has the privatise_arrays option which will hopefully do away with the need for the 'force_private` - worth a try.

[Andy Porter (arporter)]

(I've just realised this doesn't show up in our docs so I'm talking to LonelyCat124 (@LonelyCat124) about that.)

[Andy Porter (arporter)]

After discussing with LonelyCat124 (@LonelyCat124), I realise I was wrong - privatise_arrays isn't going to work with this transformation :-(

[Benjamin Went (MetBenjaminWent)]

I want to keep this test mirroring what is in the majority of the Transmute scripts currently on trunk as a means to catch when there is a change in the PSyclone repo that affects the scripts, as an early waning system basically. We also don't have any Transmute testing coverage really, so this needs to act as that till we have a better solution.

If we align this test now with the PSyclone repo, this test will not serve it's purpose.

Many thanks for the info tho.

[Oakley Brunt (oakleybrunt)]

Looks like a useful test to me, approved. Need to think about things further...

Further thoughts, need to re-review.

[Oakley Brunt (oakleybrunt)]

How are you integrating this into the working pattern of devs? Is this expected to be part of the GitHub Actions CI/CD or maybe part of the rose-stem test-suite?

[Benjamin Went (MetBenjaminWent)]

How are you integrating this into the working pattern of devs? Is this expected to be part of the GitHub Actions CI/CD or maybe part of the rose-stem test-suite?

So these tests get run when the rose app python_unit_tests get run, which is already part of the scripts group.
So it's already been interfaced directly into the existing testing mechanisms in place on trunk, just by dropping a new script into the folder.

So this test where I ran the rose app on it's own to make sure it was linked in:
https://cylchub/services/cylc-review/taskjobs/benjamin.went/?suite=psyclone-test%2Frun3

And this one where I ran the group scripts, which gets run as part of the developer suite:
https://cylchub/services/cylc-review/taskjobs?user=benjamin.went&suite=psyclone-test%2Frun5&no_fuzzy_time=0&cycles=&tasks=&task_status=waiting&task_status=expired&task_status=preparing&task_status=submit-failed&task_status=submitted&task_status=running&task_status=failed&task_status=succeeded&job_status=&order=time_desc&per_page=300

[Oakley Brunt (oakleybrunt)]

Looks good, happy to approve

[James Bruten (james-bruten-mo)]

This is quite a neat way of running these in the unit tests, so happy to approve