Delete Jules metadata copy

[James Bruten (james-bruten-mo)]

PR Summary

Sci/Tech Reviewer: Maggie (@maggiehendry)
Code Reviewer: Sam Clarke-Green (@t00sa)

This deletes lfric-jules-shared and jules-lfric metadata sections from lfric_apps now that the build system can extract the metadata from jules.
The metadata deleted is either already in, or has been copied to the Jules repo. Older versions are renamed to match Jules versions, with corresponding imports updated here.

• linked MetOffice/jules#110
• linked Lfric macros jules meta SimSys_Scripts#230

Some WPs are also updated in MetOffice/simulation-systems#625

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 Apps rose-stem suite
• 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)

As well as rose-stem testing, I've also tested that the changes to apply_macros and release_new_version in the linked PR also work by creating new Jules and LFRic releases on test branches. I've then used the metadata in these test branches to update an lfric_apps suite to ensure it will upgrade from vn3.1 to vn3.2 correctly. This all works as expected.

trac.log

Test Suite Results - lfric_apps - apps_delete_jules_meta/run2

Suite Information

Item	Value
Suite Name	apps_delete_jules_meta/run2
Suite User	james.bruten
Workflow Start	2026-04-29T10:35:41
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	james-bruten-mo/jules@copy_lfric_meta	True
lfric_apps	james-bruten-mo/lfric_apps@delete_jules_meta	False
lfric_core	MetOffice/lfric_core@3c8ccc6	True
moci	MetOffice/moci@2026.03.2	True
SimSys_Scripts	MetOffice/SimSys_Scripts@cab3315	True
socrates	MetOffice/socrates@2026.03.2	True
socrates-spectral	MetOffice/socrates-spectral@2026.03.2	True
ukca	MetOffice/ukca@1cdb9c2	True

Task Information

✅ succeeded tasks - 1185

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]

Looks good to me

[Maggie (maggiehendry)]

Thanks James Bruten (@james-bruten-mo) for undertaking this non-trivial task. It is really quite complicated. A number of questions have occurred to me whilst getting to grips with these changes trying to anticipate what will happen during the release particularly concerning the centrally installed metadata, consequences for suites etc. using at earlier revisions and upgrade macro chains. Some of these questions I have tried to answer myself by running some tests. So these comments are a mixture of questions, my understanding (please correct me), musings & comments. I have numbered particular questions.

I've also had a look at the related changes to the WPs and SimSys_Scripts too to try to get a full picture of what will happen on release.

1. Are the WP changes complete?

2. JULES is an acronym for Joint UK Land Environment Simulator so it should be "JULES" and not "Jules" throughout MetOffice repos. I sought the opinion of other JULES users in the office and they are also of the same opinion. In MetOffice/lfric_apps there are 84 instances of Jules and 368 of JULES.

From what I understand. Each time a commit is done, the centrally installed rose-meta is updated. It looks like these are symlinks to a git clone. For jules-lfric this is:

/home/users/metomi/rose-meta/jules-lfric -> .git-clones/lfric_apps.git/rose-meta/jules-lfric/

I'm assuming that it is the git clone that is updated while the symlinks remain unchanged. When this PR is committed unless updated, this link will be broken as jules-lfric won't exist in the lfric_apps git clone. After updating this symlink to point to the JULES git clone, will a suite using vn2.1 and earlier be able to import for example jules-lfric/vn2.1 as it won't exist. Will this situtation ever arise? jules-lfric should be imported via jules-lsm from vn3.0 or lfric-gungho earlier.

1. What's the process to maintain or edit symlinks in the central installation?
2. How is this managed in partner sites? Does every site have their own methods?
3. Is jules-lfric ever imported directly to a configuration?

Tracing the metadata in the LFRic-GC suite that I have a copy of, the lfric_atm app uses:

meta=lfric-lfric_atm/vn2.1

which will pick up:

> ls -l ~metomi/rose-meta/lfric-lfric_atm
/home/users/metomi/rose-meta/lfric-lfric_atm -> .git-clones/lfric_apps.git/rose-meta/lfric-lfric_atm/
> ls -l rose-meta/lfric-lfric_atm
rose-meta/lfric-lfric_atm -> ../applications/lfric_atm/rose-meta/lfric-lfric_atm//
> cat applications/lfric_atm/rose-meta/lfric-lfric_atm/vn2.1/rose-meta.conf
import=lfric-gungho/vn2.1
> ls -l ~metomi/rose-meta/lfric-gungho
/home/users/metomi/rose-meta/lfric-gungho -> .git-clones/lfric_apps.git/rose-meta/lfric-gungho/
> ls -l rose-meta/lfric-gungho
rose-meta/lfric-gungho -> ../science/gungho/rose-meta/lfric-gungho/
> more science/gungho/rose-meta/lfric-gungho/vn2.1/rose-meta.conf
import=lfric-driver/vn2.1
      =jules-lfric/vn7.8

Similarly for lfric-jules, so this all looks good. 😄. I guess the answer to "Is jules-lfric ever imported directly to a configuration?" is no.

1. I think this needs an upgrade macro to bump the jules-lsm HEAD tag.

In the PR the test branches were used to update an lfric_apps suite to ensure it will upgrade from vn3.1 to vn3.2 correctly.

1. What about from earlier revisions e.g. vn2.1?
   I created a copy of the LFRic-GC suite that I have and added a blank upgrade macro to bump the tag. I upgraded to vn3.1_t463 using the generated macro and validated against the branch metadata, which it correctly picked up. 😄

I also copied vn2.0 lfric_atm rose stem apps into branch to see if the earlier upgrade macro works. I'm trying to figure out what happens with the contents of the deleted macros:

interfaces/jules_interface/rose-meta/jules-lfric/version20_21.py
interfaces/jules_interface/rose-meta/jules-lfric/version21_22.py
interfaces/jules_interface/rose-meta/jules-lfric/version22_30.py
interfaces/jules_interface/rose-meta/jules-lfric/version30_31.py

and whether these should be added to the jules-lsm macros for those revisions...

1. After the apply_macros.py script has been applied and copied to lfric-gungho upgrade macro for example, is there any further use for the original macros?

2. At the moment these upgrade macros still exist in ~metomi/rose-meta/jules-lfric but when this branch is committed to the trunk, the git clone will be updated and I'm assuming that these will these then be deleted as these don't exist in rose-meta/jules-lfric/ in the JULES repository. Is it ok that these macros are deleted?

3. Do the upgrade macros work to add an item in jules-shared?
   Yes. Added an extra item in jules_pftparm and added to jules-lsm upgrade macro with intended error. Added and then failed validator macro as intended.

[James Bruten (james-bruten-mo)]

Thanks for taking some time to think through all the implications of this change - it's good to know someone else has given it some thought. I think I've addressed all your comments below. I haven't yet added an upgrade macro to jules-lsm but I'm happy to do that?

Are the WP changes complete?

Yes, although I was expecting to find more to change, so if you know of anywhere I've missed please point it out. I was expecting there to be a section describing using jules-shared with the UM, but maybe that doesn't exist yet? In which case it's probably worth adding.

JULES is an acronym...

We can certainly update it, but probably best done in a separate PR. I'm sure other repos will need updating too.

What's the process to maintain or edit symlinks in the central installation?

This is done automatically and managed by Dave M, but I'm not sure whether the old jules-lfric symlink will be deleted. I'll contact Dave to confirm whether it'll need some manual intervention at commit, but the end result should be that jules-lfric symlinks back to the Jules repo once this is on.

How is this managed in partner sites? Does every site have their own methods?

I don't think central metadata is used in other sites.

Is jules-lfric ever imported directly to a configuration?

I guess the implicit assumption I've been making is no. It's not in an lfric_apps application, just imported by other applications. Rose Apps would import the lfric-jules or lfric-lfric_atm metadata.

I think this needs an upgrade macro to bump the jules-lsm HEAD tag.

I'm not actually convinced that it does as the actual metadata used by apps hasn't changed. But I guess adding one won't harm anything and might help catch anything I'm missing.

What about from earlier revisions e.g. vn2.1? + questions around macros being deleted

If the earlier assumption that there are no rose-apps that directly import jules-lfric is correct then removing the macros is safe. As discussed above I think this is a valid assumption. apply_macros copies the macros into each different macro chain, so anything that imports jules-lfric will already have those macros in their chains. So those apps can still be upgraded from pre vn3.1 to the current HEAD. I've tested this with an lfric_atm app at vn2.1, upgrading to the current latest macro, vn3.1_tXXX.

[Maggie (maggiehendry)]

Thanks for taking some time to think through all the implications of this change - it's good to know someone else has given it some thought. I think I've addressed all your comments below. I haven't yet added an upgrade macro to jules-lsm but I'm happy to do that?

👍

Are the WP changes complete?

Yes, although I was expecting to find more to change, so if you know of anywhere I've missed please point it out. I was expecting there to be a section describing using jules-shared with the UM, but maybe that doesn't exist yet? In which case it's probably worth adding.

I added a comment to the simulation_systems WP with another place that needed a tweak, but I don't think you saw it. I've tried to make it clearer.

I really need to update all the docs including migrating the Sharing JULES metadata trac wiki to GitHub. I'll be updating it once I have all the reviews done. When I did the WP changes for jules-shared in the UM, I read through them and added instructions on how to pick up the JULES path where it was required an added the Shared namelists section MetOffice/simulation-systems#138. Do you think the WPs are the place to document the information that is in the Sharing JULES metadata wiki? Or sufficient to link to the wiki in the WPs once I've migrated it.

JULES is an acronym...

We can certainly update it, but probably best done in a separate PR. I'm sure other repos will need updating too.

Agreed, it needs a separate PR to change them all. However, I don't think we should be adding any more, particularly when it was initially "JULES". I've made suggestions to change these back. There's also inconsistent usage in the WP changes that I've also made a suggestion to change.

[Maggie (maggiehendry)]

These are the new Jules that were introduced. Could you please change them back so we don't introduce any more.

[James Bruten (james-bruten-mo)]

These are the new Jules that were introduced. Could you please change them back so we don't introduce any more.

Yes, done

[Maggie (maggiehendry)]

Thanks James Bruten (@james-bruten-mo). I think this is all good 😄