Skip to content

Code Management

Jump to bottom
Ali.Abdolali edited this page Jan 28, 2022 · 24 revisions

This wiki page describes the code management of this repository.

Checklist for a Code Manager of a Pull Request to develop

The pull request process is documented in this section of our Developer's Guide.

  • Make sure your develop is up to date with the authoritative repository.
  • A pull request will be accepted first to a branch of the NCEP repository, and only reintegrated to the develop branch after passing all tests, unless it has been made by a trusted repository that has followed the regression testing standards fully (make sure to communicate with the developer that the pull request has not gone straight to the develop branch if the case),
    • Regression testing: The full matrix with same y/n options as regtest/bin/matrix_ncep should be completed.
    • Comparing output of Regression Tests: matrix.comp should be used to compare results with the current develop branch.
    • Add the summary output of matrix.comp to the pull request back to the authoritative repository.
    • State which compiler you used to run the regression tests in the PR.
  • Pull requests should be separate for different features or pull requests. (Ie. branches should be single purpose)
  • Look at the code itself to confirm that code is following WW3 standard practices.
  • Make sure GOTOs were not added. Particularly, computed GOTOs will not be allowed back into the develop. An example of a computed GOTO is:
 GO TO (901,902,903) L2

In general we will strongly discourage any additional general GOTOs as if you add one, we have to remove another one from somewhere.

  • All headers of modules and routines have been updated.
  • If a new feature was added, was a new regression test added?
  • Have you updated a module that reads/writes one of the WW3 binary files (*.ww3), i.e: w3iobcmd, w3iogomd, w3iopomd, w3iorsmd, w3iosfmd, w3iotrmd, or w3src4md? If so, and you have changed the format the binary file, then ensure that you update the relevant VERxxx string. This string is located near the top of the module and should be updated to the modification date in "YYYY-MM-DD" format.
  • Are required manual updates included?
  • Should this be a new version number X.XX?
  • Run the full set of the regtests (for example at EMC we use regtests/bin/matrix_ncep to generate the list of tests with information on submitting to queue). To confirm all tests ran without error 'grep -nri error matrix.out' Then, we use matrix.comp (see: How to use matrix.comp to compare regtests with master) to confirm if answers have changed between the current master and the tested branch.

Checklist for a Developer Submitting to develop

When you are ready to create a pull request back to develop, make sure the list below has been completed and then send an email to the code manager with the branch name and answer to the questions below:

  • Did you add any GOTOs? Computed GOTOs will not be allowed back into the develop. An example of a computed GOTO is:
 GO TO (901,902,903) L2

but in general, we will strongly discourage any additional general GOTOs as if you add one, we have to remove another one from somewhere.

  • All headers of modules and routines have been updated.
  • Does a new regtest need to be made? If so have you added it and completed Checklist for Adding or Modifying a Regtest
  • Have you updated a module that reads/writes one of the WW3 binary files (*.ww3), i.e: w3iobcmd, w3iogomd, w3iopomd, w3iorsmd, w3iosfmd, w3iotrmd, w3iogrmd, or w3src4md? If so, and you have changed the format the binary file, then ensure that you update the relevant VERxxx string. This string is located near the top of the module and should be updated to the modification date in "YYYY-MM-DD" format.
  • Have you made the required manual updates?
  • Will this correspond to a new version X.XX? If yes, make a comment in your issue indicating that this including information about that the "about" description in the manual page should be.
  • Code managers will run a full set of the regtests (for example at EMC we use regtests/bin/matrix_ncep to generate the list of tests with information on submitting to queue). To confirm all tests ran without error 'grep -nri error matrix.out' then, we use matrix.comp (see: How to use matrix.comp to compare regtests with master) to confirm if answers have changed between the current master and the tested branch.

Checklist for Updating Version Number

The version number update is performed by the authoritative repository code manager. The following is the checklist of tasks when updating the version number.

  1. Update any subroutine 7.XX (7.xx, 7.XY, X.YZ, etc.) to correct version number
  2. Update version number in manual/defs.tex and manual/intro/about.tex
  3. Update version number in w3initmd.F90 (WWVER)
  4. Commit message (with correct version number) "Updated version number to 7.XX"
  5. Update milestones page with version number
  6. Update front github page (or anywhere else we are keeping track of the github number, not sure what this is yet)

Checklist for Public Release

The list of tests that will be run before a public release is created is:

Running matrix.base for the following compilers:

  • Intel (defaults in comp.Intel)
  • Intel with debug compiler options and no optimization ( opt="-c $list -O0 -assume byterecl -g -traceback -check all -fpe0 -ftrapuv -module $path_m")
  • Portland (comp.Portland)
  • GNU (comp.Gnu)
  • Run with S T and other debug flags to make sure tests run

Test NCEP operational systems:

  • GFSv16
  • GEFSv12
  • Great Lakes

Checklist for updating dev/ufs-weather-model

  • WW3
  1. Make a new branch from dev/ufs-weather-model
  2. Merge develop branch changes to the new branch
  3. Make a WW3 PR from the new branch to dev/ufs-weather-model
  • ufs-weather-model
  1. Make a new branch from ufs-weather-model
  2. In the ufs-weather-model branch, point to the new WW3 branch.
  3. After all ufs-weather-model RT is done on all the platforms, commit the WW3 PR to dev/ufs-weather-model.
  4. Update the ufs-weather-model branch to point to the dev/ufs-weather-model branch.
  5. ufs-weather-model code managers will commit the PR.
  • Create new mod_def files if a commit to WW3/develop change mod_def files.
  • Create a new base on ufs-weather-model if restsart, out_pnt and out_grd files changed.

Quick Links

Clone this wiki locally