Allow meshes to be renamed on load

[Ricky Wong (mo-rickywong)]

PR Summary

Sci/Tech Reviewer:
Code Reviewer:

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 PR??): 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?

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

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