├── .github └── workflows │ ├── publish_wps.yml │ └── requirements.txt ├── .gitignore ├── CONTRIBUTING.md ├── LICENSE ├── Makefile ├── README.md ├── env.yml ├── make.bat └── source ├── FurtherDetails ├── change_notes.rst ├── code_of_conduct.rst ├── dos_donts.rst ├── glossary.rst ├── index.rst ├── support.rst └── who.rst ├── Reviewers ├── codereview.rst ├── committinglinkedtickets.rst ├── curaterelease.rst ├── howtocommit.rst ├── images │ └── commit_process.png ├── index.rst ├── nightlytesting.rst ├── releases │ ├── jules_release.rst │ ├── lfric_apps_release.rst │ ├── um_main_release.rst │ └── um_test_release.rst └── scitechreview.rst ├── WorkingPractices ├── Diagnostics │ ├── lfric_diagnostics.rst │ └── um_stashmaster.rst ├── TestSuites │ ├── jules.rst │ ├── lfric_apps.rst │ ├── lfric_core.rst │ ├── multi-repo_testing.rst │ ├── ukca.rst │ └── um.rst ├── approvals.rst ├── branches.rst ├── common_keywords.rst ├── developing_change.rst ├── diagnostics.rst ├── documentation.rst ├── final_steps.rst ├── images │ ├── UMDWP_no_links.jpg │ ├── development_cycle.png │ ├── development_cycle_dark.png │ ├── new_ticket.png │ ├── repo_circles.png │ ├── repo_circles.svg │ ├── repos.png │ └── repos_dark.png ├── inputs.rst ├── jules_docs.rst ├── kgo.rst ├── macros.rst ├── metadata_guidance.rst ├── multi_repository.rst ├── planning_your_change.rst ├── reviews.rst ├── rose_stem.rst ├── temp_logicals.rst ├── testing.rst ├── tickets.rst └── working_practices.rst ├── _static ├── MO_MASTER_black_mono_for_light_backg_RBG.png ├── MO_MASTER_for_dark_backg_RBG.png ├── MO_SQUARE_black_mono_for_light_backg_RBG.png ├── MO_SQUARE_for_dark_backg_RBG.png └── custom.css ├── _templates └── crown-copyright.html ├── conf.py └── index.rst /.github/workflows/publish_wps.yml: -------------------------------------------------------------------------------- 1 | name: Build and Deploy Docs 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | pull_request: 8 | types: [opened,reopened,review_requested] 9 | workflow_dispatch: 10 | 11 | jobs: 12 | build-and-deploy: 13 | runs-on: ubuntu-latest 14 | 15 | steps: 16 | - name: set git user 17 | run: | 18 | git config --global user.email "umsysteam@metoffice.gov.uk" 19 | git config --global user.name "SSD Developers" 20 | - name: Check out source 21 | uses: actions/checkout@v4 22 | - uses: actions/setup-python@v5 23 | with: 24 | python-version: '3.x' 25 | - name: Install Dependencies 26 | run: | 27 | pip install -r .github/workflows/requirements.txt 28 | 29 | - name: build docs 30 | run: | 31 | make clean html 32 | 33 | - name: commit docs to gh-pages branch 34 | if: ${{ github.event_name == 'push' && github.ref_name == 'main' }} 35 | run: | 36 | git worktree add ../publish_wps 37 | cd ../publish_wps 38 | git fetch origin gh-pages 39 | git checkout gh-pages 40 | cp -r ../simulation-systems/build/html/. . 41 | git add . 42 | git commit -am "Docs build" 43 | git push -u origin gh-pages 44 | -------------------------------------------------------------------------------- /.github/workflows/requirements.txt: -------------------------------------------------------------------------------- 1 | Sphinx==6.2.1 2 | sphinx-design==0.5.0 3 | pydata-sphinx-theme 4 | sphinx-sitemap 5 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | #build output 2 | /build/ 3 | 4 | #IDE files 5 | /.idea 6 | /.venv/ 7 | /venv/ 8 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | This code of conduct is expected to be adhered to by all developers 4 | and users of Met Office Simulation Systems. 5 | 6 | 1. Be kind and respectful to others how they may be different from you. 7 | 2. Be tolerant of others but do not abuse the tolerance of others. 8 | 3. Respond to others constructively and in a reasonable time frame. 9 | 4. Communicate inclusively and contribute to the community. 10 | 5. Focus on outcomes, not processes. 11 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | BSD 3-Clause License 2 | 3 | Copyright (c) 2023, Met Office 4 | All rights reserved. 5 | 6 | Redistribution and use in source and binary forms, with or without 7 | modification, are permitted provided that the following conditions are met: 8 | 9 | 1. Redistributions of source code must retain the above copyright notice, this 10 | list of conditions and the following disclaimer. 11 | 12 | 2. Redistributions in binary form must reproduce the above copyright notice, 13 | this list of conditions and the following disclaimer in the documentation 14 | and/or other materials provided with the distribution. 15 | 16 | 3. Neither the name of the copyright holder nor the names of its 17 | contributors may be used to endorse or promote products derived from 18 | this software without specific prior written permission. 19 | 20 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 21 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 23 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 24 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 26 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 27 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 28 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 29 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 30 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line, and also 5 | # from the environment for the first two. 6 | SPHINXOPTS ?= 7 | SPHINXBUILD ?= sphinx-build 8 | SOURCEDIR = source 9 | BUILDDIR = build 10 | 11 | # Put it first so that "make" without argument is like "make help". 12 | help: 13 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 14 | 15 | .PHONY: help Makefile 16 | 17 | # Catch-all target: route all unknown targets to Sphinx using the new 18 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 19 | %: Makefile 20 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Simulation Systems 2 | 3 | This repository contains documentation that is common across the many simulation and modelling codes owned by the Met Office. 4 | 5 | To build this documentation from the top level of the project run: 6 | ``` 7 | conda env create -f env.yml 8 | conda activate sphinx_doc_env 9 | make clean html 10 | firefox build/html/index.html 11 | ``` 12 | 13 | The documentation is written in sphinx markup. To develop changes to this 14 | documentation first create an issue detailing the changes that are required. 15 | Then create a branch in a clone of this repository, linking it to your issue and 16 | regularly building your changes as described above. 17 | 18 | Once happy with your development create a pull request and request a review 19 | from MetOffice/ssdteam. -------------------------------------------------------------------------------- /env.yml: -------------------------------------------------------------------------------- 1 | name: sphinx_doc_env 2 | dependencies: 3 | - python>=3 4 | - pip 5 | - pip: 6 | - -r .github/workflows/requirements.txt 7 | -------------------------------------------------------------------------------- /make.bat: -------------------------------------------------------------------------------- 1 | @ECHO OFF 2 | 3 | pushd %~dp0 4 | 5 | REM Command file for Sphinx documentation 6 | 7 | if "%SPHINXBUILD%" == "" ( 8 | set SPHINXBUILD=sphinx-build 9 | ) 10 | set SOURCEDIR=source 11 | set BUILDDIR=build 12 | 13 | if "%1" == "" goto help 14 | 15 | %SPHINXBUILD% >NUL 2>NUL 16 | if errorlevel 9009 ( 17 | echo. 18 | echo.The 'sphinx-build' command was not found. Make sure you have Sphinx 19 | echo.installed, then set the SPHINXBUILD environment variable to point 20 | echo.to the full path of the 'sphinx-build' executable. Alternatively you 21 | echo.may add the Sphinx directory to PATH. 22 | echo. 23 | echo.If you don't have Sphinx installed, grab it from 24 | echo.https://www.sphinx-doc.org/ 25 | exit /b 1 26 | ) 27 | 28 | %SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O% 29 | goto end 30 | 31 | :help 32 | %SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O% 33 | 34 | :end 35 | popd 36 | -------------------------------------------------------------------------------- /source/FurtherDetails/change_notes.rst: -------------------------------------------------------------------------------- 1 | .. _changes: 2 | 3 | Recent Changes 4 | ============== 5 | -------------------------------------------------------------------------------- /source/FurtherDetails/code_of_conduct.rst: -------------------------------------------------------------------------------- 1 | .. _code_of_conduct: 2 | 3 | Code of Conduct 4 | =============== 5 | 6 | This code of conduct is expected to be adhered to by all developers and users 7 | of Met Office Simulation Systems. 8 | 9 | 1. Be kind and respectful to others how they may be different from you. 10 | 2. Be tolerant of others but do not abuse the tolerance of others. 11 | 3. Respond to others constructively and in a reasonable time frame. 12 | 4. Communicate inclusively and contribute to the community. 13 | 5. Focus on outcomes, not processes. -------------------------------------------------------------------------------- /source/FurtherDetails/dos_donts.rst: -------------------------------------------------------------------------------- 1 | .. _dos_donts: 2 | 3 | Do's and Don'ts 4 | =============== 5 | Please Do 6 | --------- 7 | **Consult** Code Owners and system team. This will help maintain awareness and 8 | mitigate problems early on. This is the most common root cause of problems, 9 | sometimes years later. 10 | 11 | **Plan** your work aimed at the trunk across single or multiple tickets: 12 | * Ensure tickets are not too big or small. 13 | * Coherent parts of the overall change are contained in a single ticket 14 | * Consider using an overarching ticket to link everything together 15 | 16 | **Document your work** using tickets, TRAC pages, :ref:`formal documentation ` 17 | and code comments. These help others and your future-self understand your work. 18 | 19 | **Meaningful names** for tickets, branches and variables. These help others and 20 | your future-self understand your work. "My_Branch", "Fix" are not helpful. 21 | 22 | **Be considerate** of other users/developers. Their skill-sets and working days may be very different to yours. All changes are visible to all users worldwide. 23 | 24 | **Keep the ticket status up to date.** This enables the Simulation Systems 25 | and Deployment Team to monitor the progress of your ticket and potential conflicts. 26 | 27 | **Link to tickets in other MOSRS repositories**, eg jules:#1, ukca:#72 28 | 29 | Please Do Not 30 | ------------- 31 | 32 | **Do not use svn commands.** Please use `FCM `_ for all development work. 33 | 34 | **Do not merge the trunk into your branch** for UM, JULES, UKCA and LFRic Apps changes as this breaks many aspects of how 35 | TRAC and fcm work. This will cause diffs to display incorrectly and causes 36 | database problems when merging. Instead, please create a head of trunk branch 37 | and merge in your old branch. 38 | 39 | **Do not develop using head of trunk branching if not needed.** Many aspects of 40 | the UM, JULES and UKCA workflows rely on version branching. 41 | 42 | **Licensing** - Don't add code to any project (or to any branch thereof) that 43 | has been developed under a different license without agreement from the 44 | Simulation Systems and Deployment Team. This includes lifting Fortran code or 45 | text from books. Our repositiories must not infringe copyright. 46 | 47 | **Add or link to old code** or tickets that predate MOSRS, for example... 48 | 49 | * Link to tickets in old internal repositories- links will either not resolve or be incorrect 50 | * Add a version of the UM code older than UM 9.2 as a branch to the UM repository 51 | 52 | **Request support by raising a ticket**. Newly raised tickets are not monitored. 53 | Use the appropriate :ref:`support` channels. -------------------------------------------------------------------------------- /source/FurtherDetails/glossary.rst: -------------------------------------------------------------------------------- 1 | Simulation Systems Glossary 2 | =========================== 3 | Please suggest new entries to the Simulation Systems and Deployment Team 4 | 5 | Closed Release: 6 | A release cycle where the only accepted changes to the trunk relate to a 7 | particular piece of work, either technical or scientific. A release can 8 | also be partially closed, with only one area of a code base locked down in 9 | this way, and the rest free for changes. 10 | 11 | Code Review Deadline: 12 | The date by which all tickets aiming to be included in a release have been 13 | moved into code review. 14 | 15 | Colon Keyword: 16 | The formatting pattern for certain ticket keywords. For example CR:user to 17 | indicate that "user" will be performing the Code System Review. 18 | 19 | CodeSys Review: 20 | A technical review of the changes involved in the ticket, including checks 21 | that code standards have been upheld and that the working practices have 22 | been followed. These reviews are generally completed by a member of 23 | the Simulation Systems and Deployment Team. Once a review has been approved 24 | the Code Systems Reviewer is then responsible for committing the change to 25 | the trunk. 26 | 27 | .. 28 | or the Core Capability Development Team (for LFRic only reviews). 29 | 30 | 31 | 32 | Development Window: 33 | The period of time between the release of one software version and the 34 | code review deadline for the following release in which new developments are 35 | accepted for review. 36 | 37 | Further Commit: 38 | Where a problem is found with a ticket after it has been committed, any 39 | additional commits needed are associated with the same ticket and labelled 40 | as a "Further Commit". Only essential and immediate fixes are treated this 41 | way. 42 | 43 | Known Good Output (KGO): 44 | In order to verify that the model output hasn't been modified by a set of changes 45 | the test suite contains a stored set of output as a reference. This is known 46 | as the KGO and changes that alter this require special treatment. For more 47 | information see :ref:`kgo`. 48 | 49 | Head of Trunk: 50 | The most recent code revision on the trunk. Branches are taken from here 51 | when the work being done *has* to be built on top of changes already made 52 | since the last revision. 53 | 54 | Linked Ticket: 55 | Work that spans two or more repositories, requiring tickets that should be 56 | treated together and committed as a group. 57 | 58 | Overarching Ticket: 59 | Where a piece of work has been split into multiple sections and tickets an 60 | extra ticket can be used to track this work. It should be closed when the 61 | whole arc has been completed. 62 | 63 | Regression: 64 | A set of tests that prove that a set of code changes have not degraded the 65 | model output. Comparisons are made between the results produced and the 66 | Known Good Output. 67 | 68 | SciTech Review: 69 | A science or technical review, completed by someone who is familiar with 70 | the area being changed. The aim of this review is to confirm that the 71 | changes made do what they say they should, and that the method used was 72 | appropriate. 73 | 74 | Simulation Systems and Deployment Team: 75 | The team responsible for the oversight of these working practices. For 76 | more information see :ref:`ssd`. 77 | 78 | Simulation Systems Governance Group: 79 | The governing body that oversees the work of the Simulation Systems and 80 | Deployment Team. 81 | 82 | Version: 83 | Each release of the codebase is completed by tagging the latest revision of 84 | the trunk with a version number. This version should be used for creating 85 | code branches from and will also be used by the parallel suite teams as a 86 | starting point for creating the next operational suite. -------------------------------------------------------------------------------- /source/FurtherDetails/index.rst: -------------------------------------------------------------------------------- 1 | .. _further_details: 2 | 3 | Further Details 4 | =============== 5 | 6 | .. toctree:: 7 | :maxdepth: 1 8 | :caption: Further Details 9 | 10 | who 11 | support 12 | glossary 13 | code_of_conduct 14 | dos_donts 15 | change_notes -------------------------------------------------------------------------------- /source/FurtherDetails/support.rst: -------------------------------------------------------------------------------- 1 | .. _support: 2 | 3 | Support 4 | ======= 5 | 6 | Level 0- Self help & Peer Support 7 | --------------------------------- 8 | Self-help and using the people around you should always be your first port of 9 | call. Time spent here will likely solve your problem or at least better describe 10 | it. 11 | 12 | Consider contacting relevant Code, Configuration or Suite Owners. 13 | 14 | Level 1- GitHub Discussions 15 | --------------------------- 16 | If your problem persists, then describe and discuss it on GitHub Discussions: 17 | 18 | * `LFRic `_ 19 | * `UM `_ 20 | * `JULES `_ 21 | * `Mule `_ 22 | 23 | Level 2- Support Teams 24 | ---------------------- 25 | If you still require assistance, then contact the appropriate support team. 26 | Please respect the clear demarcations between the scope for different teams. 27 | 28 | Core Capability Development Team (formally LFRic Team): 29 | * Support windows for LFRic releases TBC 30 | 31 | Simulation Systems and Deployment Team (formerly UM System Team and CRUM team) supports: 32 | * UM, Shumlib and JULES versions released in the last 12 months, 33 | * main version used in the Met Office Operational Suite. 34 | * specific climate configurations .. todo - details of which configs 35 | 36 | 37 | Escalation 38 | ---------- 39 | Sometimes things go wrong or different parties disagree. If discussions between 40 | developer, code/config owners and reviewers cannot resolve the situation then it 41 | should be escalated to the manager of the Simulation Systems and Deployment Team 42 | in the first instance. They will consult appropriately to make the best balanced 43 | and impartial decision. If this is unsuccessful, the ultimate (but very rarely 44 | used) decision authority about code that may be committed to the trunk lies with 45 | the Simulation Systems Governance Group. 46 | -------------------------------------------------------------------------------- /source/FurtherDetails/who.rst: -------------------------------------------------------------------------------- 1 | Who's Who 2 | ========= 3 | Every member of the community acts in one or more roles, depending on the work 4 | at hand. These roles often align to different teams for practical purposes. 5 | 6 | User 7 | ---- 8 | Users, in general, are anticipated to: 9 | 10 | * Edit and manage rose suites via the roses repositories 11 | * Edit suite tasks to manage code version (including use of upgrade macros), 12 | branches, science configuration and other settings to their needs 13 | * Manage their usage of compute resource in-line with relevant guidance 14 | * Ensure the scientific integrity of their use case 15 | 16 | Notably, users in this context do not edit source code. 17 | 18 | Developer 19 | --------- 20 | Developers, in general, build on the User role: 21 | 22 | * Write and edit source code 23 | * Follow the Working Practices, even if their work is not intended for the trunk. 24 | * Manage their work to allow reasonable time for approvals and reviews. 25 | 26 | Notably, the Working Practices encourage and require engagement with other 27 | roles. This helps promote cohesion and consistency, ultimately underpinning 28 | confidence in the models as a whole. 29 | 30 | .. _code_owner: 31 | 32 | Code Owner 33 | ---------- 34 | Code Owners and their deputies take responsibility for defined parts of the codebase: 35 | 36 | * Working knowledge of the code, and any supporting items such as metadata 37 | * Generally, focus will be on the scientific/functional aspects of the code, 38 | but also includes consideration of technical aspects with support from the 39 | Simulation Systems and Deployment Team 40 | * Oversee the general arc of development of their sections 41 | * Review and sign-off all changes to the code they own on an acceptable 42 | timescale 43 | * In some cases they may make suggestions regarding changes outside of their section 44 | * Often act as the Sci/Tech reviewer if their section is the primary focus of a change 45 | 46 | .. _config_owner: 47 | 48 | Configuration Owner 49 | ------------------- 50 | Configuration owners are people that have chosen to protect a model 51 | configuration (a specific arrangement on input settings and options) using the 52 | rose-stem test harness. 53 | 54 | * Working knowledge of the configuration 55 | * Generally, focus will be on the scientific/functional aspect of the 56 | configuration, but also includes consideration of technical aspects with 57 | support 58 | * Maintain, update and retire configurations to ensure they are relevant 59 | and useful 60 | * Will often be the owner or a experienced user of standalone science 61 | evaluation suites that may be used to understand the magnitude of changes 62 | in model evolution 63 | * Review and sign-off all changes to model output on an acceptable timescale 64 | 65 | Importantly, rose-stem are the single source of truth for pass/fail protection of model evolution. 66 | 67 | .. _scitech_reviewer: 68 | 69 | Sci/Tech Reviewer 70 | ----------------- 71 | 72 | A Sci/Tech reviewer is assigned for every ticket and comprises the first stage 73 | of review that considers the change as a whole. Further details are linked from 74 | the :ref:`Working Practices page`. In some cases, the reviewer can 75 | delegate parts of the work to another person. 76 | 77 | Reviews should be turned around on a reasonable timescale and follow the SciTech 78 | review guidance. 79 | 80 | It is the responsibility of the developer to identify and arrange the 81 | Sci/Tech reviewer. Often they will be someone in the same team as the developer 82 | or the most relevant code owner. 83 | 84 | .. _code_reviewer: 85 | 86 | Code Reviewer 87 | ------------- 88 | 89 | The Code Reviewer performs the 2nd stage of review for every ticket. 90 | Further details are described :ref:`Working Practices page`. 91 | 92 | Reviews should be turned around on a reasonable timescale and follow the Code 93 | Review guidance. 94 | 95 | It is the responsibility of the developer to arrange the code reviewer. 96 | 97 | **UM, LFRic Apps, JULES, UKCA and Shumlib** reviews are arranged by contacting 98 | the Simulation Systems and Deployment Team. 99 | 100 | **LFRic Core** reviews are arranged by contacting the Capability Development Team, 101 | or moving the ticket into "ready_for_code_review" state. Tickets in this state 102 | are allocated reviewers at the weekly team meeting. 103 | 104 | .. _ssd: 105 | 106 | Simulation Systems and Deployment Team 107 | -------------------------------------- 108 | 109 | The Simulation Systems and Deployment Team are responsible for the various 110 | codebases that comprise the Simulation Systems. 111 | 112 | * 4th line operational support to Met Office operational NWP system (excludes seasonal forecasting) 113 | * Support for the last 12 months worth of UM, JULES, UKCA and shumlib releases to Met Office and partners 114 | * Delivering releases and maintaining supporting infrastructure 115 | * Overseeing the Working Practices and supporting documentation and mandating their use 116 | * Curation of the trunks and supporting systems 117 | * Coordination and collaboration with other system owners to provide overall seamless support 118 | * Support for UM Climate Configurations 119 | * Support and releases for the Met Office Coupling Infrastructure (MOCI) 120 | 121 | All efforts are delivered on a best-endeavors basis, with all requests being 122 | triaged. Team members contribute to work outside of this project. 123 | 124 | The team can be contacted at umsysteam@metoffice.gov.uk. 125 | 126 | .. _cap_dev_team: 127 | 128 | Core Capability Development Team 129 | -------------------------------- 130 | The Core Capability Development Team are responsible for the LFRic Infrastructure to 131 | support the Next Generation Modelling Systems. 132 | 133 | The team can be contacted at corecapabilitydevelopmentteam@metoffice.gov.uk. 134 | 135 | LFRic questions can also be directed to meto-lfric@metoffice.gov.uk. 136 | .. todo: flesh out the description here 137 | 138 | .. _hpc_opt_team: 139 | 140 | HPC Optimisation Team 141 | --------------------- 142 | 143 | The HPC optimistation team take a general lead in matters relating to compute 144 | performance of the UM, LFRic and other systems. 145 | 146 | * Examine and improve the performance and scalability of the UM and coupled models. 147 | * Develop and maintain GCOM, the communications layer used by the UM and other systems in the Met Office. 148 | * Development and support of the UM Packing/Unpacking?, Dump and I/O routines. 149 | * Benchmarking UM software for HPC evaluations/procurement. 150 | * Act as 'code' owners for performance-related aspects of the UM, notably OpenMP and compiler directives 151 | 152 | The team can be contacted at Sci_Weath_hpc_opt@metoffice.gov.uk. 153 | 154 | Momentum Partnership Team 155 | ------------------------- 156 | 157 | The Momentum Partnership Team is responsible for engagement and support with users and developers at Core and Associate `Momentum Partner `_ organisations. The team can be contacted at momentum_partnership@metoffice.gov.uk. 158 | -------------------------------------------------------------------------------- /source/Reviewers/codereview.rst: -------------------------------------------------------------------------------- 1 | .. _code_review: 2 | 3 | Code and System Review 4 | ====================== 5 | 6 | Purpose of the review 7 | --------------------- 8 | The purpose of the code/system review is to analyse a change for its impact 9 | and to ensure that all concerned parties are made aware of changes that are required. 10 | 11 | Fundamentally this review is to ensure that the change is well thought-out and 12 | that no system aspects have been missed. The review should be an active one and should question anything that is poorly coded. 13 | 14 | Reviewer responsibilities and checkpoints 15 | ----------------------------------------- 16 | The Code/System review template exists to help you think through all the areas 17 | of concern. A completed :ref:`review template