New function space options for coordinate fields

[tommbendall]

PR Summary

Sci/Tech Reviewer: @thomasmelvin
Code Reviewer: @EdHone

This adds two new namelist options for the function spaces used by the coordinate fields:

1. The coordinate fields can be in a Wtheta space (discontinuous in the horizontal, continuous in the vertical)
2. The coordinate space used by multigrid meshes is not tied to the coordinate space used by the prime mesh

When Wtheta is used as the function space, the vertical coordinate order is kept as 0, making the coordinates linear in the vertical. These options are an optimisation to the coordinate fields, which will facilitate us moving to coord_order=2 which gives a significant boost in NWP score:

1. using a Wtheta space allows us to have fewer DoFs per cell (see below)
2. keeping a lower coordinate order for multigrid meshes has minimal scientific impact but is a small optimisation, and also helps to avoid the bug reported in Halo exchange hangs for high-order W0 field on multigrid mesh in high-res runs #239

Details

The key changes in this PR are:

1. components/driver/rose-meta/lfric-driver/HEAD/rose-meta.conf, introduction of two new namelist options:

• to specify the function space used for the coordinates
• to allow coordinate order to be specified separately for multigrid meshes

2. components/driver/source/driver_fem_mod.f90:

• in general, exploit tensor product structure of coordinate spaces, using linear polynomials in the vertical irrespective of the coord_order variable
• the exception to the above is when coord_system='xyz', which which case the coordinate space should be isotropic and coord_order is used in both horizontal and vertical directions
• introduce a Wtheta-like coordinate space, which is horizontally-discontinuous and vertically-continuous
• allow coordinate order for multigrid meshes to be set independently from coordinate order for prime mesh

3. components/driver/rose-meta/lfric-driver/versions.py:

• add upgrade macro for new namelist options

4. Kernels specifying the Wchi space have been changed to ANY_SPACE_9 (this is not necessary but feels safe)
5. Add new namelist options to configuration.nml files and unit-tests where relevant

This table illustrates some of the coordinate function space options:

Wchi order 1	Wchi order 2 (main)	Wchi order 2 (this branch)	Wtheta order 1	Wtheta order 2

Please See

This branch is built on the changes in #284, and until that is merged the diff on this PR will also include the changes from that branch. I have created PRs in my own fork to show useful diffs for reviewing:

• Diff for code changes in this PR
• Diff for test branch to show action of upgrade macro

Linked-To

• LFRic Apps #179, which picks up these changes
• there will also need to be a linked JEDI-LFRic PR

Blocked-By

This branch includes the changes from #284, which are necessary to be able to safely use a Wtheta space for the coordinate fields.

• LFRic Core #284 and its linked ticket, LFRic Apps #277

Blocks

The ultimate aim of this work is to facilitate moving to coord_order=2 to give a better representation of the orography.

• LFRic Apps #180

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 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 - test_coord_space_core/run4

Suite Information

Item	Value
Suite Name	test_coord_space_core/run4
Suite User	thomas.bendall
Workflow Start	2026-03-10T17:18:10
Groups Run	developer

Dependency	Reference	Main Like
lfric_core	tommbendall/lfric_core@TBendall/TestCoordSpace	False
SimSys_Scripts	MetOffice/[email protected]	True

Task Information

✅ succeeded tasks - 384

Task Information

✅ succeeded tasks - 372

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

[thomasmelvin]

All the changes look good.

As a comment for future development I think it would be good if correctly specified the element order when creating functions spaces (instead of being built on a single element order for the derahm complex as was originally envisioned).

i.e. The lowest order W0 space would be:
w0_fs = function_space_collection%get_fs(mesh, 1, 1, W0)
and our default Wtheta space would be
wt_fs = function_space_collection%get_fs(mesh, 0, 1, Wtheta)