Allow meshes to be renamed on load

[Ricky Wong (mo-rickywong)]

PR Summary

Sci/Tech Reviewer: cjohnson-pi
Code Reviewer: Matthew Hambley (@MatthewHambley)

Access to meshes in input files produced from the mesh generators should contain unique mesh names by design. The mesh names are used as a more user-friendly means to reference meshes in downstream applications. This however becomes an issue when applications such as lfric2lfric are required to read in multiple files produced for other applications. Applications which generate their input files may have used mesh(es) with identical names (e.g. dynamics, multigrid_l1, etc) in their individual tasks which produce output.

Adopting a practice of naming a mesh after the process/scheme that uses it, rather than a name that describes the mesh is not ideal. However, this practice has come about as a result of XIOS iodef.xml files which reference the specific mesh name, having the same mesh names allow for a template iodef.xml to be used. The alternative would significantly increase the number of iodef.xml files (with only a mesh name change between them). Having a constant mesh name, thus results in meshes from separate files having the same name.

This poses a problem for applications like lfric2lfric, where it needs to read different meshes from one or more files, were the meshes might have the same name in each of the files.

The simple solution here is to allow an application to read in the meshes (which have the same name) from individual files as separate instances and allow the application (lfric2lfric) to rename when the instance are created. This allows a method for an application to not violate the unique naming of objects restrictions in the mesh collections. This neatly allows lfric2lfric to use the meshes it requires (with the names they wish) without impacting the upstream applications that produced the input files.

Implementation

Allowing the meshes to be renamed before storing them in the collections is relatively straight forward. An optional argument on the method on the mesh constructors (global/local) allow the mesh objects to be renamed on creation before storing them in the collection. After that, the application should only worked with the "stored mesh names".

Complications

• Mesh inter-grid maps: These where designed to be valid at the point of mesh generation, i.e. applications should only use maps between meshes sourced from the same file. In this case, the meshes are being renamed and potentially from separate files. The maps themselves are logged from mesh to mesh via their ids, which remain unique, so that shouldn't be an issue. The complication comes when identifying which maps from which files should be assigned to which mesh during setup.

  The solution here is to log at the point of creation the original mesh name and file that the mesh came from. This means that during the intergrid map setup, maps are only read, created and attached if the meshes (using their original names) came from the same file. After the maps are read and attached, the rest of the code should proceed as normal.

• Chi transforms (Out-of-Scope see Refactor code implementing initial chi transform with respect to North Pole and Schmit stretching #460): This does a lot of unnecessary things, however changes to make it more sensible change kgos. So it should be done as separate PR.

• Mapping factors: Implementation of mapping factors is too low in the code, in addition it computes for every mesh in the mesh collection which is overkill. It should only need to do this for meshes that are required to be aligned. The routine was overloaded so that a mapping factor could be computed between a global_mesh and a single reference global mesh rather than the whole collection.

Potential downstream issues

• What mesh name is used for downstream applications? (Out-of-scope) In lfric2lfric's case, multiple meshes may be read in, which may or may or may not be the same. Though what mesh names should be referenced in the output file? original source, original target or something else determined by the application?

Linked PRs

• linked Update LFRic2LFric to store unique names for it's source and destination meshes lfric_apps#729

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)

Test Suite Results - lfric_core - lfric2lfric_in_and_out/run1

Suite Information

Item	Value
Suite Name	lfric2lfric_in_and_out/run1
Suite User	ricky.wong
Workflow Start	2026-08-21T12:38:16
Groups Run	developer

Dependency	Reference	Main Like
lfric_core	mo-rickywong/lfric_core@lfric2lfric_in_and_out	False
SimSys_Scripts	MetOffice/SimSys_Scripts@cab3315	True

Task Information

✅ succeeded tasks - 433

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

[cjohnson-pi]

Sci/Tech review: Thanks for making these changes to enable using meshes with the same name in lfric2lfric. I am generally happy with the implementation with only a couple of minor comments. But please could I encourage the developer to move any changes that are not essential to this work to a separate PR - it will make it a lot easier for reviewers to give a proper assessment of the work.

[Ricky Wong (mo-rickywong)]

All comments addressed, test-suite green, passing back to reviewer

[cjohnson-pi]

Many thanks for your response to my previous review. I am happy with those changes. There are still just a couple of minor changes to be made, including reverting further changes that are not required for this ticket.

[Ricky Wong (mo-rickywong)]

Back with cjohnson-pi

[cjohnson-pi]

Thanks for completing the requested changes.

[Matthew Hambley (MatthewHambley)]

Generally looks okay. I've noted a few issues of code style. If you want to postpone them to a subsequent ticket, please raise the ticket and link to it on this one.

I wont insist on the string changes because I see string handling is shot throughout this change and modifying it would delay further. But consider them for future.

[Matthew Hambley (MatthewHambley)]

Is this an informative or a narrative message? Should it be at log level "info" or "debug"?

[Ricky Wong (mo-rickywong)]

Following my reasoning, I'd say debug.

[Matthew Hambley (MatthewHambley)]

Is there a reason for not using character(*) and therefore not having to worry about string length?

Are mesh_names and rename_to co-indexed arrays? If so, is there a way to do this so they aren't.

[Ricky Wong (mo-rickywong)]

Reason for not using character(*), --- habit. not sure about the co-indexed, Would seem ideally suited for duplicate mesh namelists i.e.

&Mesh
file_prefix=
file_mesh_name=
app_mesh_name=
prepartitioned=
/

with the instance_key_member being the app_mesh_name, but I think that is out of scope on this PR.

[Matthew Hambley (MatthewHambley)]

If the arrays are not the same size, rule of least surprise suggests the user should at least be warned of this. It might even be an error condition. At the moment it looks like the rename just doesn't happen, silently.

Furthermore, why do the names have to be the same size?

[Ricky Wong (mo-rickywong)]

Good spot on the silent warning. Same size is co-indexing issue if mesh_names is array >1 how do you know which rename goes to which mesh unless you ensure the same size.

[Matthew Hambley (MatthewHambley)]

Given that incoming strings could be larger than str_def, you might be better off using character(:), allocatable :: name. Because character arrays are magic, you can still use name = rename_to and it will be automatically allocated to the correct size.

[Matthew Hambley (MatthewHambley)]

More co-indexing of arrays?

[Ricky Wong (mo-rickywong)]

Yup, necessary evil for want factor out code that was committed in the wrong place to begin with. The whole lot needs rethinking, so this is more of a stepping stone

[Matthew Hambley (MatthewHambley)]

No need for return statements at the end of subroutines.

[Matthew Hambley (MatthewHambley)]

Is it worth saving 2 characters on get_original_name?

[Matthew Hambley (MatthewHambley)]

Two character saving again.

[Ricky Wong (mo-rickywong)]

Like to couch it as a 25% saving

[Matthew Hambley (MatthewHambley)]

Two character saving?

[Ricky Wong (mo-rickywong)]

Was more to mean get the name of the mesh in its origin file.