Skip to content

Fix rose stem io demo and lbc demo#356

Open
Ricky Wong (mo-rickywong) wants to merge 3 commits intoMetOffice:mainfrom
mo-rickywong:fix_rose_stem_io_demo_and_lbc_demo
Open

Fix rose stem io demo and lbc demo#356
Ricky Wong (mo-rickywong) wants to merge 3 commits intoMetOffice:mainfrom
mo-rickywong:fix_rose_stem_io_demo_and_lbc_demo

Conversation

@mo-rickywong
Copy link
Copy Markdown
Contributor

@mo-rickywong Ricky Wong (mo-rickywong) commented Apr 30, 2026

PR Summary

Sci/Tech Reviewer:
Code Reviewer: James Bruten (@james-bruten-mo)

io_demo and lbc_demo apps have rose-app.conf in rose-stem which use rose-metadata at HEAD instead of vn3.1.
Having them set to HEAD means that they are not affected by the upgrade macro and fail for updates.

However setting them to vn3.1 causes failure in validation because there is no upgrade macro for io_demo to migrate vn3.1 to HEAD.

This fixes the current issue by:

  • Correcting the rose-stem configs to points to vn3.1 as intended
  • Making vn3.1 io_demo metadata the same as head, making the empty upgrade macro consistent.

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)

Core test-suite green as expected

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
@james-bruten-mo
Copy link
Copy Markdown
Collaborator

Don't think this requires an SR

Copy link
Copy Markdown
Contributor

@EdHone Ed Hone (EdHone) left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a stop-gap before we can discover or implement a solution to getting upgrade macros working properly in lfric_core I understand the need for this change.
My main issues with this change are regarding the use of the 3.1 tag for the changed metadata. Would it be possible to introduce a new vn3.1_t232 tag and copy the current HEAD to that tag and then use that as the base for this issue? We could remove it after the 3.2 release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

4 participants