File metadata and Forecast reference Time Scalar to reduce post processing from lfric core

[mo-marqh]

PR Summary

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

This change provides extra configuration to the output file metadata, using an XIOS scalar to define a container for a forecast reference time that will be populated by lfric_core's lfric_xios interface (see linked PR)

• linked reducing post-processing of XIOS output lfric_core#204
• linked https://github.com/JCSDA-internal/lfric-jedi/pull/1254
• is blocked-by Release management: version string and components #446
• is blocked-by Output Metadata Validation Testing #455

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
  style guidelines
• Comments have been included that aid undertanding and enhance the
  readability of the code
• My changes generate no new warnings

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 (eg. kgo changes)
• I have added tests to cover new functionality as appropriate (eg. system
  tests, unit tests, etc.)
• Any new tests have been assigned an appropriate amount of compute resource
  and have tests 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 - scalar_frt/run5

Suite Information

Item	Value
Suite Name	scalar_frt/run5
Suite User	mark.hedley
Workflow Start	2026-04-20T09:32:25
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	mo-marqh/lfric_apps@scalar_frt	False
lfric_core	mo-marqh/lfric_core@ca8f2ad	True
moci	MetOffice/moci@2026.03.2	True
SimSys_Scripts	MetOffice/SimSys_Scripts@4387949	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

❌ failed tasks - 2

Task	State
rose_ana_lfricinputs_um2lfric-aquaplanet_lbc_azspice_gnu_fast-debug-64bit	failed
rose_ana_lfricinputs_um2lfric-aquaplanet_lbc_ex1a_gnu_fast-debug-64bit	failed

✅ succeeded tasks - 1181

⌛ waiting tasks - 2

Task	State
housekeep_azspice	waiting
housekeep_ex1a	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 (eg. PsyKAl-lite, Kernal
  inteface, 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)]

mo-marqh - Before I review can i seek clarification about the failing tests listed in the description, is this PR ready for review?

Also, could you rename the PR to give a better desctiption of the changes please

[mo-marqh]

mo-marqh - Before I review can i seek clarification about the failing tests listed in the description, is this PR ready for review?

Also, could you rename the PR to give a better desctiption of the changes please

failing tests need fixing, there are only two left to do, I'll get right on that.
it's ready for sci/tech review, tests need fixing for code review

Pr renamed

[mo-marqh]

regarding the two failing rose ana tests in lfric inputs Lottie Turner (@mo-lottieturner)

these are due to the new forecast_reference_time coordinate being included in the output file and referenced by the data variables.

so, in the updated run_lfricinputs_um2lfric-aquaplanet_lbc_azspice_gnu_fast-debug-64bit/checkpoint_um2lfric_000001.nc file, then
(ncdump -ts work/1/run_lfricinputs_um2lfric-aquaplanet_lbc_azspice_gnu_fast-debug-64bit/checkpoint_um2lfric_000001.nc | grep -e 'time =' -e forecast_reference)

	float forecast_reference_time ;
		forecast_reference_time:name = "forecast_reference_time" ;
		forecast_reference_time:standard_name = "forecast_reference_time" ;
		forecast_reference_time:units = "seconds since 2014-11-05 00:00:00" ;
		forecast_reference_time:_Storage = "contiguous" ;
		forecast_reference_time:_Endianness = "little" ;
		forecast_reference_time:_NoFill = "true" ;
...
forecast_reference_time = "2014-11-05" ;
...
time = "2014-11-05", "2014-11-05 03", "2014-11-05 06", "2014-11-05 09" ;

& reference changes such as

theta:coordinates = "forecast_reference_time Mesh2d_face_y Mesh2d_face_x" ;

are added.

this is expected behaviour for this change, but would benefit from Lottie Turner (@mo-lottieturner) 's view

if approved, then i think that static data files located in ~umadmin would be required to be updated for tests to pass (at code-review merge time, iirc)

[mo-marqh]

cross checking with input UM file:

noting lbtim=11

• the field is a forecast from T2 valid at T1.
• the Proleptic Gregorian calendar is used for T1 and T2
  (https://code.metoffice.gov.uk/doc/um/latest/papers/umdp_F03.pdf pp20)

module load scitools

import iris.fileformats.um as um
fields = list(um.um_to_pp('/home/users/umadmin/standard_jobs/lfricinputs/inputs/aquaplanet.lbc.ff'))
[print(f'lbtim: {f.lbtim} | lbyr: {f.lbyrd} | lbmond: {f.lbmond} | lbdatd: {f.lbdatd} | lbhrd: {f.lbhrd} | lbmind: {f.lbmind} | lbsecd: {f.lbsecd}') for f in fields[0:1]]

lbtim: 11 | lbyr: 2014 | lbmond: 11 | lbdatd: 5 | lbhrd: 0 | lbmind: 0 | lbsecd: 0
[None]

which is consistent with

forecast_reference_time = "2014-11-05" ;

(noting that ncdump -t trims off the time fragments if they're 00)
Lottie Turner (@mo-lottieturner)

[Lottie Turner (mo-lottieturner)]

Hi Mark, thanks for the ping. When I nccmp the new output with the kgo (as in the rose-ana test, without the var-diff-count limit) I get this:

$ nccmp -Fdf --exclude=Mesh2d home/users/umadmin/standard_jobs/lfricinputs/kgo/lfricinputs_um2lfric-aquaplanet_lbc_azspice_gnu_fast-debug-64bit/vn3.0/checkpoint_um2lfric_000001.nc /data/scratch/mark.hedley/cylc-run/scalar_frt/run2/work/1/run_lfricinputs_um2lfric-aquaplanet_lbc_azspice_gnu_fast-debug-64bit/checkpoint_um2lfric_000001.nc

DIFFER : Failed to find variable forecast_period in file "/data/scratch/mark.hedley/cylc-run/scalar_frt/run2/work/1/run_lfricinputs_um2lfric-aquaplanet_lbc_azspice_gnu_fast-debug-64bit/checkpoint_um2lfric_000001.nc".

which seems different enough to your expected changes of adding forecast_reference_time that I'm wary of it

[Ed Hone (EdHone)]

The way the changes have been implemented is completely fine - my only question is whether the frt/fp time formatting needs to be so ubiquitous across the code base (obviously it was before, but that was more a limitation of the previous implementation). My understanding is that its more essential for NWP than for climate runs. Would it be possible to get some clarity from some of the downstream data owners on whether there is a different expectation for the formatting of time for different configurations.

I would also suggest this would make it easier to correct the LFRic inputs issues as the start dumps probably shouldn't have time formatted as frt/fp

[James Frost (jfrost-mo)]

As a downstream consumer of LFRic data (via CSET), the removal of forecast_period should not cause any major problems, as we already have have code to construct it, as it is occasionally missing. Having just the validity time as the only varying dimension of time in a forecast is easier to reason about (noting #423).

Also in this pull request is a change from time_origin to the CF compliant forecast_reference_time. I am strongly supportive of this renaming, as it is something we currently have to fix downstream when we load the data.

[iboutle]

I'm unclear why this file has been changed, but other "grid_def" files have not?

And also, what is the implication for adding the frt to the grid_defs for diagnostics which don't use the grid_defs (there are plenty that just use axis and domain refs)? Will these be missing the frt? Should it be added to either the domain or axis refs instead?

[DanStoneMO]

There will be a linked lfric-jedi PR to match this, I will link it once it's ready.

[DanStoneMO]

lfric-jedi PR now live at: https://github.com/JCSDA-internal/lfric-jedi/pull/1254

[github-actions]

⚠️ Hello mo-marqh!

Your CLA signature was found on the base branch, but you appear to have modified the CONTRIBUTORS.md file in this PR.

Please do not edit the CONTRIBUTORS.md file. If you have already signed the CLA, revert changes to the file and your signature will be picked up.