Development Workflow

Table of Contents

1. Open an Issue
2. Develop new feature or bug fix
3. Test! Test! Test!
4. Submit Pull Request
5. Code Merged to Master
6. Post-merge Testing

Open an Issue

All development, whether for a new feature, bug fix, re-engineering task, or documentation or data update, MUST begin with opening an issue. An open issue allows for transparency, developer and community input, assignment of the task, and progress tracking.

To open an issue, follow these steps

Develop new feature or bug fix

Coding should take place in a branch, or ideally, in a fork

Test Test Test - THIS SECTION IS OUT OF DATE, PLEASE IGNORE - UPDATE TO FOLLOW

NEMSfv3gfs regression testing on Cheyenne (work in progress)

Prerequisites:

• access to public repositories ccpp-framework, ccpp-physics and FMS (under http://www.github.com/NCAR)
• access to private repositories FV3, NEMS, NEMSfv3gfs (under http://www.github.com/NCAR)
• password-less GitHub access via https from Cheyenne

How to set up password-less GitHub access on Cheyenne

• search the web for git config credential.helper store or git config credential.helper cache
• make sure to load the git module before making those changes: module load git/2.10.2

Instructions (on Cheyenne):

• check out the latest version of ccpp-framework from http://www.github.com/NCAR/ccpp-framework
• go to ccpp-framework/test/nemsfv3gfs and adjust the configuration file regression_test_nemsfv3gfs_cheyenne.cfg
  (see documentation in regression_test_nemsfv3gfs.py)
• load the git module via

. setenv_cheyenne.sh       # for bash
source setenv_cheyenne.sh  # for csh/tcsh

• (recommended) start a screen session (see https://linuxize.com/post/how-to-use-linux-screen)
• execute

./regression_test_nemsfv3gfs.py --config=regression_test_nemsfv3gfs_cheyenne.cfg

• go for lunch or (recommended) a lunchtime run as running the tests will take some time
• once the tests and the run are done, watch out for a line reading

REGRESSION TEST WAS SUCCESSFUL

or

REGRESSION TEST FAILED

• the compile logs and the output for the individual regression tests can be found in

$BASEDIR/rt_YYYYMMDDTHHMMSS/tests/log_$MACHINE.$COMPILER

where $BASEDIR is configured in the regression test config file described above, $MACHINE is the name of the system (cheyenne, theia, ...) and $COMPILER the configuration option compiler in the regression test config file.

How to make adjustments and rerun the tests manually?

While most of the wonderful development made by ccpp-framework developers will pass the tests right away, it may occasionally be necessary to make adjustments and rerun the tests manually (instead of rerunning the script regression_test_nemsfv3gfs.py). This is the procedure:

• locate the work directory $WORKDIR=$BASEDIR/rt_YYYYMMDDTHHMMSS, which is the top-level directory of the NEMSfv3gfs main repository
• regression test run directories are located in $WORKDIR/FV3_RT/rt_$$ where $$ stands for a unique PID
• replace/update code as needed in the main repository or the submodules
• change to $BASEDIR/rt_YYYYMMDDTHHMMSS/tests and execute

ACCNR=$ACCOUNT NEMS_COMPILER=$COMPILER RUNDIR_ROOT=$RUNDIR ./rt.sh -l $RTCONF 2>&1 | tee rt.log

where $ACCOUNT corresponds to the configuration option account in the regression test config file, $COMPILER to , $RTCONF to the configuration option config, and $RUNDIR to $BASEDIR/rt_YYYYMMDDTHHMMSS/FV3_RT, or, for convience, to $PWD/../FV3_RT when executing rt.sh from $BASEDIR/rt_YYYYMMDDTHHMMSS/tests

• this will create a new regression test directory $WORKDIR/FV3_RT/rt_$$ (see rt.log)
• it is also possible to manually run the compile command instead of executing rt.sh; however, this is more complicated as the compiler options may depend on which test is failing (contact a GMTB developer in this case)

Submit Pull Request

Code Merged to Master

Post-merge Testing