linear_model app with UM_PHYSICS compiler flag set to true

[cjohnson-pi]

PR Summary

Sci/Tech Reviewer: Steven Sandbach (@ss421)
Code Reviewer: James Bruten (@james-bruten-mo)

To allow the linear and nonlinear code to be run in the same executable, the linear_model code needs to be
able to run with UM_PHYSICS set to true. This includes requiring the physics code to be extracted during the build. I propose that given that the linear model will be used in this format operationally, the linear_model app should also be tested in this format.

The main changes are:

• Updating the linear_model app makefile so that it is almost the same as the lfric_atm makefile, but with the addition of the linear code.
• Use the lfric_atm app build and optimisation options. These are linked to directly from the linear_model app makefile (rather than copying into the linear_model application directories) - which will allow any changes to lfric_atm options to be immediately picked up by the linear_model app.
• Add a few switches in the code (for the create_physics_prognostics), around the ifdef UM_PHYSICS that is now turned on.
• Split up some of the code so that it is not called by the linear model. eg. create_prognostics and linear_diagnostics.

The jedi_lfric_tests application has not been updated. I have tried to update this in exactly the same way as the linear_model app and most of the tests pass. However, a few tests fail (e.g. run_jedi_lfric_tests_tlm_tests_nwp_gal9-4OMP-C12_MG_azspice_gnu_fast-debug-64bit). I believe that the reason for this is that the jedi_lfric_tests already have a optimisation/meto-azspice/psykal/global.py that is required for the adjoint code. Therefore it is not possible to simply point to the lfric_atm optimisation. A follow-on ticket will be required to update the jedi_lfric_tests. This will update the makefile so that it is similar to the linear_model app makefile, update the jedi_lfric_tests build and optimisation files so that they are combination of the lfric_atm and adjoint files. Also, the jedi_lfric_tests integration tests will need to be removed as I don't believe it is possible to run these with UM_PHYSICS.

• blocks Enable jedi_lfric to run lfric_atm forecast configurations #512

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
• [ x 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 - ifdef/run42

Suite Information

Item	Value
Suite Name	ifdef/run42
Suite User	christine.johnson
Workflow Start	2026-05-20T07:57:44
Groups Run	suite_default

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

Test Suite Results - lfric_apps - ifdef/run43

Suite Information

Item	Value
Suite Name	ifdef/run43
Suite User	christine.johnson
Workflow Start	2026-05-20T09:03:11
Groups Run	lfric_atm_extra

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	cjohnson-pi/lfric_apps@ifdefphys	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 - 169

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

[DanStoneMO]

Tested this against jedi and all works well. No linked jedi PR will be needed.

[Steven Sandbach (ss421)]

Thankyou for the update. This change is required by #512 which builds on this branch. Ive added a blocks PR to the summary.

I've added a few comments but happy with the change so Im handing the change over to James Bruten (@james-bruten-mo) for code review.

[Steven Sandbach (ss421)]

Im not sure what the policy is but I think the start date here should not change.

[cjohnson-pi]

The makefile was copied from lfric_atm which has a start date of 2017. Happy to be advised by the code reviewer.

[Steven Sandbach (ss421)]

If its a new file - should it just be 2026?

[cjohnson-pi]

Not sure. It was copied from lfric_atm, which started with 2017. Happy to be advised by code reviewer.

[Steven Sandbach (ss421)]

Are these updated because they have been missed in previous updates?

[cjohnson-pi]

Yes given that there is no physics, it seems safer to switch them all to none. In addition this then satisfies the new switch in create_physics_prognostics.

[Steven Sandbach (ss421)]

Thankyou. Is this already applied in the rose configurations?

[cjohnson-pi]

Yes. Although some settings are not triggered (so it might have !!aerosol) due to the rose meta validation (which is not applied to the example configuration files).

[Steven Sandbach (ss421)]

Passing to James Bruten (@james-bruten-mo) for code review.

[mo-cjsmith]

Initialisation changes look fine.

[James Bruten (james-bruten-mo)]

I think this is mostly fine. I was slightly surprised at the number of changes required in gungho. I imagined that any physics initialisation required there was already done for the apps using the physics schemes? Similarly for the new create_physics_model_data subroutine?

[cjohnson-pi]

I think this is mostly fine. I was slightly surprised at the number of changes required in gungho. I imagined that any physics initialisation required there was already done for the apps using the physics schemes? Similarly for the new create_physics_model_data subroutine?

The reason for the changes in gungho is that currently when ifdef UM_PHYSICS is turned on, a lot of physics is initialised (which is required for lfric_atm). But we don't want to initialise this for the linear model as the linear model doesn't use physics. So I've tried to rearrange the code slightly so that the linear model doesn't call as much of the physics initialisation, and anything that it does call has an extra switch that can be turned off.

Its a bit of a peculiar code change. The linear model doesn't use physics which is why at the moment the UM_PHYSICS is not turned on. But as jedi need the linear and nonlinear models to be run in the same executable, we have to turn UM_PHYSICS on in the compilation. i.e. its turn it on but don't use it.

[James Bruten (james-bruten-mo)]

Thanks Christine, that makes sense so happy to approve.
Given this blocks the jedi PR I may ask another SSD member to get this on over the next few days as I'm away for the next week.

[Matthew Hambley (MatthewHambley)]

Code owner (buid system) review: A couple of questions regarding build system changes.

[Matthew Hambley (MatthewHambley)]

I don't understand the need for this change. Does it not do exactly the same thing as the original line but in a more complicated manner?

[cjohnson-pi]

I'm now calling this lfric_atm file from the linear_model app. So when calling from the linear_model app, PROJECT_DIR=linear_model. But when calling from the lfric_atm app, PROJECT_DIR=lfric_atm. So you are correct that when running lfric_atm it does exactly the same thing.

[Matthew Hambley (MatthewHambley)]

I don't think there should be a need to do this. What is it achieving?

[cjohnson-pi]

Hmm, I'm not exactly sure what it is achieving. My aim is to use the same compiler options as lfric_atm - so I just copied that over. I think that if its missing then there is a failure - although I would need to double check.