reducing post-processing of XIOS output

[mo-marqh]

PR Summary

Sci/Tech Reviewer: Ed Hone (@EdHone)
Code Reviewer: Erica Neininger (@ericaneininger)

This PR refactors the metadata manipulation that is currently done within a file post processing function.

Only one post processing operation remains, which is only needed in the edge case of a limited area model using projected coordinates. This may be able to be done with XIOS in future, but right now this remains a feature gap.

For all other metadata specifications, these are implemented using XIOS, and removed from post processing.

This also removes the need for MPI init_wait() calls from most usage patterns.

This change introduces a soft requirement for new XML configuration, forecast reference times will only be output if an appropriately named scalar is provided, normally through XML configuration files (see linked PR)

• linked File metadata and Forecast reference Time Scalar to reduce post processing from lfric core lfric_apps#90

Code Quality Checklist

(Some checks are automatically carried out via the CI pipeline)

• 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

Testing

• I have tested this change locally, using the LFRic Core rose-stem suite
• If required (e.g. API changes) I have also run the LFRic Apps test suite
  using this branch
• 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_core - xios3-compatibility-stable3/run8

Suite Information

Item	Value
Suite Name	xios3-compatibility-stable3/run8
Suite User	mark.hedley
Workflow Start	2026-04-20T08:38:38
Groups Run	developer

Dependency	Reference	Main Like
lfric_core	mo-marqh/lfric_core@xios3-compatibility-stable3	False
SimSys_Scripts	MetOffice/SimSys_Scripts@4387949	True

Task Information

✅ succeeded tasks - 390

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
  tooscollabdevteam@metoffice.gov.uk

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

[Ed Hone (EdHone)]

Sci/Tech review

Overall a well-formatted change that dramatically reduces our dependency on file post-processing in the majority of cases which will enhance the resilience of our code. It's good that the flag for post-processing is decided on a file-by-file basis.

• Could you please re-name the PR to more accurately reflect the scope of the changes (i.e. reducing post-processing of XIOS output) as there are more changes that need to be made before we can run with XIOS3.
• It would also be good to see a side-by-side comparison of the NetCDF headers of output files (say from C12 NWP runs) to confirm that the contents are similar (this can be handled on the linked ticket in #lfric_apps#90)
• It would be nice to implement an integration test which confirm that the file format is correct when the frt scalar is incuded in the iodef.xml - I'm happy if you want to create this as a separate issue

[Mike Hobson (mike-hobson)]

I'm tagged on this as the code owner for infrastructure/utilities - so I've only looked at lfric_core_version_mod.F90.

The file has no preprocessor directives in it, so the filename should really have a lower case .f90 suffix.

[Mike Hobson (mike-hobson)]

We don't need dates in the copyright notice, anymore.

Suggested change

	! (C) Crown copyright 2026 Met Office. All rights reserved.
	! (C) Crown copyright Met Office. All rights reserved.

[Mike Hobson (mike-hobson)]

We don't do upper case keywords in LFRic - can you make all keywords lower case

[Mike Hobson (mike-hobson)]

I don't like relying on Fortran's default public access. Certainly, in other constants modules in LFRic, we have a private statement just below the implicit none and then explicitly list everything we want to make public. I would prefer that to be done here, too.

[Mike Hobson (mike-hobson)]

Do we need to put more thought into what we are using for the version? A simple string like this is fine for simple equivalence if-tests, but if we stored separate major/minor/patch values they could be more easily used in comparisons.

I realise (from the capital keywords) that this is probably taken from what we do with the UM - but could we do better?

[mo-marqh]

i've updated the version signifier as per your comments Mike Hobson (@mike-hobson)

However, in making the code paths testable within
https://github.com/MetOffice/lfric_core/pull/204/changes#diff-7b2b4b22ec4e6a0fc950c090cc358397c4bad8b19f2dbe717ee0c8efdf26ac79R18
i've introduced a set of global variables, which is not great
Found 1 new files with global variables.

Please may I ask for a bit of advice on options and preference here?
Is setting these to public, parameter acceptable?
This would make testing the variants harder, the test setting of inputs may also be not desirable.
If parameter or other, how might I better unit test the new code?

many thanks, mark

[Mike Hobson (mike-hobson)]

Hi mark, I brought up the issues you mentioned above at our morning meeting, so the "hive mind" could have a think about it!

First of all, the three integers should definitely be parameters.

That leads us on to how do we unit test the lfric_core_version_char function if those variables are parameters. We discussed using #ifdef UNIT_TEST to declare the variables as either parameters or not - but that's pretty ugly as it leads to two sets of declarations in the source. I managed to get some code working where I defined a preprocessor macro that contained parameter or just public depending on the UNIT_TEST macro and used that in the declarations:

#define PASTE(a) a
#ifdef UNIT_TESTING
#define PARAM PASTE(public)
#else
#define PARAM PASTE(parameter)
#endif

integer, PARAM :: major = 3

But really that's no less ugly than the naive method.

In the end, the team decided that the best way to go was to make your lfric_core_version_char function take the version information it needs as arguments. It makes the call a little uglier and you'd have to add the parameters to the use statement, but unit testing then becomes trivial. It's probably the best solution from a software engineering viewpoint, too. A function should be self-contained to work on things it gets through its API, rather than working on externally defined global variables.

What do you think?

[mo-marqh]

thank you Mike Hobson (@mike-hobson)

i have re-implemented, based on this feedback