diff --git a/source/Development/TestSuites/lfric_apps.rst b/source/Development/TestSuites/lfric_apps.rst index f45acafa..71d62133 100644 --- a/source/Development/TestSuites/lfric_apps.rst +++ b/source/Development/TestSuites/lfric_apps.rst @@ -16,7 +16,7 @@ Local testing: Alternatively, a single application can be built and run locally using `these instructions - `__ + `__ This test does not use rose or cylc and is particularly useful for checking for compile errors while developing. diff --git a/source/Development/TestSuites/lfric_core.rst b/source/Development/TestSuites/lfric_core.rst index 75a7d570..8c7c37b6 100644 --- a/source/Development/TestSuites/lfric_core.rst +++ b/source/Development/TestSuites/lfric_core.rst @@ -31,10 +31,3 @@ developer suite). It is also possible to run on a single platform, eg. ``-z group=ex1a``. To select which meto EX machine is used, add ``-S USE_EX=true``. - -.. tip:: - - For more details on LFRic testing including details of unit tests please - visit the `LFRic testing trac wiki page - `__. - diff --git a/source/Development/documentation.rst b/source/Development/documentation.rst index 9e209513..d1194335 100644 --- a/source/Development/documentation.rst +++ b/source/Development/documentation.rst @@ -36,9 +36,8 @@ alongside the code. This is then compiled using Sphinx into the webpages above. The UM documentation papers are written in LaTeX and stored in a separate repository. Guidelines for editing the UM documentation papers are available - `here `_ + :ref:`here `. -.._ umdp: https://code.metoffice.gov.uk/trac/um/wiki/WorkingPractices/Documentation/UpdatingUMDPs LFRic Apps and Core also use doxygen to document the code and all changes should include appropriate doxygen changes to go with them. Doxygen guidelines diff --git a/source/Development/inputs.rst b/source/Development/inputs.rst index a1d4dcca..6eff6f3f 100644 --- a/source/Development/inputs.rst +++ b/source/Development/inputs.rst @@ -51,11 +51,6 @@ Rose GUI for users to switch it on. Additionally, sometimes the metadata needs to be modified without changing a namelist variable. Guidance for updating the metadata :ref:`is available `. -.. - Could do with thinking about how the JULES metadata could be included in this - document in the future, rather than the JULES wiki page - (https://code.metoffice.gov.uk/trac/jules/wiki/WorkingPractices#NamelistsUpgradeMacrosMetadata) - .. note:: JULES developers also need to :doc:`update the JULES documentation diff --git a/source/Development/metadata_guidance.rst b/source/Development/metadata_guidance.rst index 7682d309..f99a218d 100644 --- a/source/Development/metadata_guidance.rst +++ b/source/Development/metadata_guidance.rst @@ -53,16 +53,14 @@ have identical metadata regardless of the repository where they reside (e.g. UM). Shared JULES metadata is in the process of being migrated to -`rose-meta/jules-shared -`__, -which resides in the JULES repository. The sub-directories are imported -by **rose-meta/um-atmos** and **rose-meta/jules-standalone** and is manually -synced with a copy in LFRic. Please see `Sharing JULES metadata -`__ for +``rose-meta/jules-shared``, in the JULES repository. The sub-directories are +imported by **rose-meta/um-atmos** and **rose-meta/jules-standalone** and is +manually synced with a copy in LFRic. Please see `Sharing JULES metadata +`__ for more details including what should be in `jules-shared -`__ +`__ and in `jules-standalone, jules-lfric or um-atmos -`__. +`__. When developing shared JULES metadata, you will need :ref:`linked pull requests `. The metadata migration is currently dictated by LFRic porting of science, although the ultimate aim is to have a single source of truth. diff --git a/source/Development/planning_your_change.rst b/source/Development/planning_your_change.rst index e20870e0..00d2853e 100644 --- a/source/Development/planning_your_change.rst +++ b/source/Development/planning_your_change.rst @@ -56,9 +56,8 @@ something wrong. Please do seek advice. coding standards and things to avoid, so it is useful for the developer to be aware of these. -* `UMDP3 (UM and JULES FORTRAN) - `__ -* `LFRic Coding Styles +* :ref:`Fortran Coding Styles ` +* `LFRic Coding Styles (which build on the above) `__ * `PEP 8 (Python) `__ diff --git a/source/Development/rose_stem.rst b/source/Development/rose_stem.rst index 4b8ee802..ad4343d5 100644 --- a/source/Development/rose_stem.rst +++ b/source/Development/rose_stem.rst @@ -78,8 +78,8 @@ manually configured, such as JULES. .. note:: - LFRic Apps has a `detailed set of wiki pages - `__ + LFRic Apps has a `detailed set of pages + `__ that document the structure and options available for their suite. diff --git a/source/Development/temp_logicals.rst b/source/Development/temp_logicals.rst index 40f11e27..0d2fdc1a 100644 --- a/source/Development/temp_logicals.rst +++ b/source/Development/temp_logicals.rst @@ -115,21 +115,7 @@ examining existing variables in the subroutines listed in the table above. An upgrade macro and Rose metadata will be required to add the temporary logical into the GUI and make it available to model users. See :ref:`inputs` -for further information. UM developers are also expected to fill in a -`temporary fixes summary template -`__ -and `the temporary logical table -`__ prior to the -review process. - -.. - Note: Have we got a page on upgrade macros? (i.e. brief instructions on how - to write one?) I wonder if we need one - I can only see a discussion on - what they are and how to apply one! - - Should the temporary logical page and the summary wiki page be extended to - all repositories? I can't see one for JULES at the moment. This is - something to think about making consistent. +for further information. After the release cycle diff --git a/source/Development/um_docs.rst b/source/Development/um_docs.rst index 0bb44157..6f2bb23c 100644 --- a/source/Development/um_docs.rst +++ b/source/Development/um_docs.rst @@ -1,3 +1,5 @@ +.. _umdp: + Unified Model Documentation Papers (UMDPs) ========================================== diff --git a/source/FurtherDetails/coding_style.rst b/source/FurtherDetails/coding_style.rst index d086d0cd..60b33c5c 100644 --- a/source/FurtherDetails/coding_style.rst +++ b/source/FurtherDetails/coding_style.rst @@ -1,3 +1,5 @@ +.. _standards: + ================== Software standards ================== diff --git a/source/Reviewers/codereview.rst b/source/Reviewers/codereview.rst index ab7aa93a..a0f32741 100644 --- a/source/Reviewers/codereview.rst +++ b/source/Reviewers/codereview.rst @@ -110,16 +110,9 @@ will include areas such as: Generally this is about making sure the code complies with the relevant style guides, and is consistent with the design of the code it sits in. - * `UMDP3 (UM and JULES FORTRAN) - `__, - * `LFRic Coding Styles - `__ - * `PEP 8 (Python) `__ - - `This page - `__ - provides some common (though UM-centric) things to confirm and think - about. It is not an exhaustive list, just a starting point. + * :ref:`Fortran Coding Styles ` + * `LFRic Coding Styles (which build on the above) + `__ Final decision points and actions --------------------------------- diff --git a/source/Reviewers/howtocommit.rst b/source/Reviewers/howtocommit.rst index 7c52cc3a..6a444b9d 100644 --- a/source/Reviewers/howtocommit.rst +++ b/source/Reviewers/howtocommit.rst @@ -116,9 +116,8 @@ To update the test suite for an upgrade macro, please run: .. note:: The ``-\-jules-path`` option is only required if there are - linked `jules-shared - `__ - metadata changes. + linked changes to the ``rose-meta/jules-shared`` directory in the + Jules repository. .. tab-item:: JULES @@ -187,10 +186,10 @@ To update the test suite for an upgrade macro, please run: this by checking out an appropriate working copy, and exporting the environment variable ``ROSE_META_PATH=/path/to/core``. - For UM PRs, if there are linked `jules-shared - `__ - metadata changes then a suitable Jules source will need to be included - in the `ROSE_META_PATH` as described above. + For UM PRs, if there are linked changes to the + ``rose-meta/jules-shared`` directory in the Jules repository, then a + suitable Jules source will need to be included in the `ROSE_META_PATH` + as described above. .. dropdown:: Temporary Logical? @@ -434,7 +433,7 @@ KGO differently* #. Copy the new KGO to the correct locations: `JULES KGO commands - `__ + `__ #. Rerun the rose-stem tests to make sure nothing is broken. diff --git a/source/Reviewers/releases/mule_release.rst b/source/Reviewers/releases/mule_release.rst index c0a74295..0c031692 100644 --- a/source/Reviewers/releases/mule_release.rst +++ b/source/Reviewers/releases/mule_release.rst @@ -6,7 +6,7 @@ Mule Release .. note:: Additional details for the shumlib/mule releases can be seen `here - `__ + `__ Releasing Mule diff --git a/source/Reviewers/releases/shumlib_release.rst b/source/Reviewers/releases/shumlib_release.rst index 9777e1cd..f4ce9fa8 100644 --- a/source/Reviewers/releases/shumlib_release.rst +++ b/source/Reviewers/releases/shumlib_release.rst @@ -6,7 +6,7 @@ Shumlib Release .. note:: Additional details for the shumlib/mule releases can be seen `here - `__ + `__ Releasing Shumlib diff --git a/source/Reviewers/scitechreview.rst b/source/Reviewers/scitechreview.rst index 4e440227..468d46c2 100644 --- a/source/Reviewers/scitechreview.rst +++ b/source/Reviewers/scitechreview.rst @@ -35,10 +35,10 @@ The Science / Technical reviewer should * Ensure that the code has no unwanted side-effects -* Ensure that the code is written to the standards laid out in `UMDP3 - `__ or - `LFRic Coding Styles - `__. +* Ensure that the code is written to the standards laid out in + :ref:`Fortran Coding Standards ` or `LFRic Coding Styles + `__ + (which build on the first). * Make sure that the in-line documentation is accurate and sufficient.