Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apps macro wps #261

Merged
merged 11 commits into from
Dec 10, 2024
20 changes: 14 additions & 6 deletions source/Reviewers/howtocommit.rst
Original file line number Diff line number Diff line change
Expand Up @@ -166,6 +166,14 @@ then you will need to upgrade the test-suite.
where `vnX.Y_tZZZZ` is the `AFTER_TAG` of the latest upgrade macro.
The upgrade is expected to fail for the `fab_jules`, `metadata_checker` and `umdp3_checker` apps.

.. tab-item:: LFRic Apps + Core

.. code-block:: RST

apply_macros.py vnX.Y_tZZZZ [--apps=/path/to/apps] [--core=/path/to/core] [--jules=/path/to/jules]

where `vnX.Y_tZZZZ` is the `AFTER_TAG` of the latest upgrade macro and the others are paths to the relevant sources. Apps defaults to the current location. Core and Jules default to reading the `dependencies.sh` file in the Apps source. A copy of `apply_macros.py` is available at `$UMDIR/SimSys_Scripts/lfric_macros`.

.. dropdown:: New rose-stem app?

If the ticket introduces a new rose-stem app, but doesn't otherwise have a macro
Expand All @@ -191,11 +199,12 @@ then you will need to upgrade the test-suite.
rose macro --validate -M path/to/working_copy/rose-meta

.. note::
For UM tickets, if there are linked `jules-shared
<https://code.metoffice.gov.uk/trac/jules/browser/main/trunk/rose-meta/jules-shared>`_
metadata changes these will need to be added to the metadata
path. Please see the :ref:`rose config-edit
example<metadata_changes>`.

LFRic Apps tickets will require an LFRic Core source to use. You can do this by checking out an appropriate working copy, and exporting the environment variable `ROSE_META_PATH=/path/to/core`.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm guessing theres no chance of pointing ROSE_META_PATH at an fcm link?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, don't think so. Fortunately, a new app is probably quite a rare happening.

For UM tickets, if there are linked `jules-shared
<https://code.metoffice.gov.uk/trac/jules/browser/main/trunk/rose-meta/jules-shared>`_
metadata changes then a suitable Jules source will need to be included in the `ROSE_META_PATH` as described above.


.. dropdown:: Temporary Logical?
Expand Down Expand Up @@ -492,7 +501,6 @@ Supporting data is stored in the filesystems of our machines and changes to use
.. note::
The numbered run directory must be included in the suite name, eg. `name-of-suite/run1`.


5. Verify the checksums updated properly by retriggering the failed checksums. First retrigger
``export-source``, and then when complete ``export-source_xc40`` if new checksums are present
there (there is no need to retigger spice). You may need to change the maximum window extent
Expand Down
23 changes: 19 additions & 4 deletions source/WorkingPractices/inputs.rst
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ metadata :ref:`is available <metadata_guidance>`.
work with the model.

Changes to the metadata which don't involve namelist changes may or may not
require an upgrade macro. If you are unsure whether a UM change needs an
require an upgrade macro. If you are unsure whether a change needs an
upgrade macro, then run the following command on your branch:

.. code-block::
Expand All @@ -63,10 +63,25 @@ upgrade macro, then run the following command on your branch:
If all of the tests pass then there is no requirement to add an upgrade macro.
If any of the metadata tests fail, then the developer should add a blank upgrade
macro which contains no upgrade commands but simply points the rose stem suite
to the new metadata.
to the new metadata. The SSD team are also available to advise on whether an upgrade macro is necessary.

..
The above should probably be extended to LFRic eventually.
.. tip::

When editing metadata you should always check that the new metadata appears as expected in the gui, including testing that invalid settings raise appropriate warnings. The command to open the gui is in general:

.. code-block::

rose edit -C rose-stem/app/APP-NAME

For LFRic Apps a few extra changes are required:

.. code-block::

export ROSE_PYTHONPATH=$PYTHONPATH
export ROSE_META_PATH=/path/to/valid/core
rose edit -C rose-stem/app/APP-NAME

This requires an LFRic Core working copy at an appropriate revision to be available. It is also necessary to run from the top level of the Apps working copy to ensure rose metadata paths are valid.

How to add an upgrade macro to your branch
------------------------------------------
Expand Down
50 changes: 46 additions & 4 deletions source/WorkingPractices/macros.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,11 @@
Upgrade Macros
==============

To create an upgrade macro, the developer must edit a ``versions.py`` file which is used
to update the various apps in the rose stem suite to accept the namelist changes. The upgrade
macros also form the basis of the ``rose app-upgrade`` script applied by a user wishing to
upgrade from one version of a model to the next.
.. important::

When developing Upgrade Macros, they must be tested using a test branch (see :ref:`testing`).

Comment on lines +6 to +9
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nice addition :)

To create an upgrade macro, the developer must edit a ``versions.py`` file which is used to update the various apps in the rose stem suite to accept the namelist changes. The upgrade macros also form the basis of the ``rose app-upgrade`` script applied by a user wishing to upgrade from one version of a model to the next.

The ``versions.py`` file containing upgrade macros can be found in the following locations:

Expand All @@ -20,6 +21,11 @@ The ``versions.py`` file containing upgrade macros can be found in the followin

``rose-meta/jules-standalone/versions.py``

.. tab-item:: LFRic Core + Apps

| ``applications/<APPLICATION>/rose-meta/lfric-<APPLICATION>/versions.py``
| Variations on this theme occur, eg. LFRic Apps science sections or Components in LFRic Core


Within the file a blank upgrade macro will typically look like this:

Expand Down Expand Up @@ -73,3 +79,39 @@ This command can then be run on a **test** branch (see :ref:`testing`).
namelists and changing the value that a particular variable takes.
A `tutorial <http://metomi.github.io/rose/doc/html/tutorial/rose/furthertopics/upgrading.html>`_
is also available.


Upgrade Macros in LFRic
-----------------------

.. warning::

Namelist files in application example directories are not currently updated by the Apply Macros script. This feature is intended to be introduced, but for now, developers still need to manually update those files.

The organisation of LFRic metadata is different from other repositories (UM + Jules) as the metadata is stored with the Science or Application section it is associated with and is then imported by other apps that require it. This helps modularise the LFRic code but complicates macro chains as different apps may require different chains depending on the metadata they import. A simple implementation of macros in this case might require duplication of a particular macro if its metadata is imported multiple times. This is unsatisfactory as it makes mistakes more likely and requires more effort.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I feel like explaining the alternative solution adds too much bulk to this section. I suggest stopping at "complicates macro chains."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure


To solve this, macros in LFRic Apps are applied using a wrapper script which will read the added macros and combine them in versions.py files where the metadata is imported. Therefore when adding macros, the macro should be added in the versions.py file in the same metadata directory as the metadata it is applying. It will then be shared as appropriate by the ``apply_macros.py`` script. For example, if a change to metadata is made in ``science/gungho/rose-meta/lfric-gungho``, the macro should be added to the ``versions.py`` file in that directory. This will then be copied to other ``versions.py`` files that import gungho metadata, eg. lfric_atm, transport etc.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
To solve this, macros in LFRic Apps are applied using a wrapper script which will read the added macros and combine them in versions.py files where the metadata is imported. Therefore when adding macros, the macro should be added in the versions.py file in the same metadata directory as the metadata it is applying. It will then be shared as appropriate by the ``apply_macros.py`` script. For example, if a change to metadata is made in ``science/gungho/rose-meta/lfric-gungho``, the macro should be added to the ``versions.py`` file in that directory. This will then be copied to other ``versions.py`` files that import gungho metadata, eg. lfric_atm, transport etc.
To solve this, macros in LFRic Apps are applied using a wrapper script which will read the added macros and combine them into the versions.py files for the apps where that metadata is imported. Therefore when adding macros, the macro should be added in the versions.py file in the same directory as the metadata change being made. It will then be shared as appropriate by the ``apply_macros.py`` script. For example, if a change to metadata is made in ``science/gungho/rose-meta/lfric-gungho``, the macro should be added to the ``versions.py`` file in that directory. This will then be copied to other ``versions.py`` files that import gungho metadata, eg. lfric_atm, transport etc.

A couple of suggested tweaks. I also wonder if the "for example" should be a new (indented?) paragraph to lower the size of the block of text.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done both all of those suggestions


.. important::

Some complex macro commands may be dependent on the order in which they are applied. If macros are copied by the wrapper script, the order they are applied will always be determined by the reverse metadata import order. For example, lfric_atm imports gungho metadata, which itself imports components/driver. If all 3 sections have an associated macro, then the macro commands would be applied in the order: components/driver, gungho, lfric_atm.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Some complex macro commands may be dependent on the order in which they are applied. If macros are copied by the wrapper script, the order they are applied will always be determined by the reverse metadata import order. For example, lfric_atm imports gungho metadata, which itself imports components/driver. If all 3 sections have an associated macro, then the macro commands would be applied in the order: components/driver, gungho, lfric_atm.
Some complex macro commands may be dependent on the order in which they are applied. As macros are copied by the wrapper script, the order they are applied will always be determined by the reverse metadata import order. For example, lfric_atm imports gungho metadata, which itself imports components/driver. If all 3 sections have an associated macro, then the macro commands would be applied in the order: components/driver, gungho, lfric_atm.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done


.. tip::

The wrapper script will read the ``dependencies.sh`` file in your LFRic Apps working copy and will checkout a temporary copy of the LFRic Core source if required. Some Core metadata changes will also modify the Core rose apps. In this case make sure to also commit these changes back to the core branch.
Copy link
Collaborator

Choose a reason for hiding this comment

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

"if required" = "if a working copy is not provided"?

So affected core apps are modified in the temporary checkout? I guess not since they'd need a core metadata change to go with that so you'll have had a working copy around already.

Is it worth modifying the script to print to say which working copies were modified in the process of applying the macro to make it clearer which ones will need committing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that's right about the temporary copy.
In the script at the moment (line 980 in the 2nd PR if you wanted a peek) it checks if macros were applied to a temporary checkout of the lfric core source (and doesn't tidy it if there were changes). Do you think it's worth explicitly stating all working copies that need committing?


To add upgrade macros to LFRic the following steps can be followed:

1. Checkout an LFRic Apps working copy and update the core source in ``dependencies.sh`` if required.
Copy link
Collaborator

Choose a reason for hiding this comment

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

"if required" = "if you have LFRic Core changes"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

2. Add your upgrade macros. These **must** be added to the versions.py file associated with the metadata they are changing.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
2. Add your upgrade macros. These **must** be added to the versions.py file associated with the metadata they are changing.
2. Add your upgrade macros. These **must** be added to the versions.py file in the same directory as the metadata being changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

3. Run the Upgrade Macro script - this **must** be done in a test branch (see :ref:`testing`). This is located in the `SimSys_Scripts github repo <https://github.com/MetOffice/SimSys_Scripts>`_ (at meto an up to date clone is available in $UMDIR/SimSys_Scripts). The syntax for running is:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
3. Run the Upgrade Macro script - this **must** be done in a test branch (see :ref:`testing`). This is located in the `SimSys_Scripts github repo <https://github.com/MetOffice/SimSys_Scripts>`_ (at meto an up to date clone is available in $UMDIR/SimSys_Scripts). The syntax for running is:
3. Run the Upgrade Macro script - this **must** be done in a test branch (see :ref:`testing`). This is located in the `SimSys_Scripts github repo <https://github.com/MetOffice/SimSys_Scripts>`_ (at meto an up to date clone is available in $UMDIR/SimSys_Scripts). The syntax for running is:
Suggested change
3. Run the Upgrade Macro script - this **must** be done in a test branch (see :ref:`testing`). This is located in the `SimSys_Scripts github repo <https://github.com/MetOffice/SimSys_Scripts>`_ (at meto an up to date clone is available in $UMDIR/SimSys_Scripts). The syntax for running is:
3. Run the Upgrade Macro script in a test branch (see :ref:`testing`). This is located in the `SimSys_Scripts github repo <https://github.com/MetOffice/SimSys_Scripts>`_ (at meto an up to date clone is available in $UMDIR/SimSys_Scripts). The syntax for running is:

shifting the emphasis of the test branch to the important box below to help the flow of this point (I first read it as the test branch is located in the simsys scripts github repo!)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, reads better, cheers


.. code-block::

SimSys_Scripts/lfric_macros/apply_macros.py vnXX.Y_tTTTT -a Apps -c Core -j Jules

The Apps, Core and Jules options are paths to sources for each of these. Apps will default to the present location (so it is recommended to launch from an Apps working copy). Core and Jules will default to reading the ``dependencies.sh`` file in the Apps source if not provided.

.. tip::

The apply_macros script requires python >= 3.9. At the Met Office this can be achieved by ``module load scitools``.
8 changes: 4 additions & 4 deletions source/WorkingPractices/testing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -79,12 +79,12 @@ commands, noting that ``--jules-path`` is only required if you have
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| JULES | ``./bin/upgrade_jules_test_apps vnX.X_tXXXX`` |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| LFRic | ``apply_macros.py vnX.Y_tZZZZ [--apps=/path/to/apps] [--core=/path/to/core] [--jules=/path/to/jules]`` |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

..
| LFRic | *Macro capabilities are currently in development* |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------+
.. tip::

.. todo: add an LFRic upgrade macro command... and make these more consistent?
The `apply_macros.py` script is located in the `SimSys_Scripts github repo <https://github.com/MetOffice/SimSys_Scripts>`_ (at meto an up to date clone is available in $UMDIR/SimSys_Scripts).

.. warning::
Please ensure that Cylc7 is used with `update_all.py` @vn13.5. This is fixed at HoT and either Cylc7 or Cylc8 can be used.
Expand Down