2.1. Quick Start Guide
This chapter provides a brief summary of how to build and run the SRW Application. The steps will run most smoothly on Level 1 systems. Users should expect to reference other chapters of this User’s Guide, particularly Section 2.3: Building the SRW App and Section 2.4: Running the SRW App, for additional explanations regarding each step.
2.1.1. Install the Prerequisite Software Stack
SRW App users who are not working on a Level 1 platform will need to install the prerequisite software stack via spack-stack prior to building the SRW App on a new machine. Users can find installation instructions in the spack-stack documentation. The steps will vary slightly depending on the user’s platform, but detailed instructions for a variety of platforms are available in the documentation. Users may also post questions in the ufs-community Discussions tab.
Once spack-stack been successfully installed, users can move on to building the SRW Application.
2.1.2. Building and Running the UFS SRW Application
For a detailed explanation of how to build and run the SRW App on any supported system, see Section 2.3: Building the SRW App and Section 2.4: Running the SRW App. Figure 2.1 outlines the steps of the build process. The overall procedure for generating an experiment is shown in Figure 2.2, with the scripts to generate and run the workflow shown in red. An overview of the required steps appears below. However, users can expect to access other referenced sections of this User’s Guide for more detail.
Clone the SRW App from GitHub:
git clone -b develop https://github.com/ufs-community/ufs-srweather-app.gitCheck out the external repositories:
cd /path/to/ufs-srweather-app/ ./manage_externals/checkout_externalsSet up the build environment and build the executables:
./devbuild.sh --platform=<machine_name>where
<machine_name>is replaced with the name of the user’s platform/system. Valid values include:derecho|gaeac6|hera|hercules|noaacloud|orion|ursa|For additional details, see Section 2.3.4.1, or view Section 2.3.4.2 to try the CMake build approach instead.
Users on a Level 2-4 system must download and stage data (both the fix files and the IC/LBC files) according to the instructions in Section 3.2.3. Standard data locations for Level 1 systems appear in Table 2.4.
Load the python environment for the workflow. Users on Level 2-4 systems will need to use one of the existing
wflow_<platform>modulefiles (e.g.,wflow_macos) and adapt it to their system. Then, run:source /path/to/ufs-srweather-app/etc/lmod-setup.sh <platform> module use /path/to/ufs-srweather-app/modulefiles module load wflow_<platform>where
<platform>is a valid, lowercased machine name (seeMACHINEin Section 3.1.1 for valid values), and/path/to/is replaced by the actual path to theufs-srweather-app.After loading the workflow, users should follow the instructions printed to the console. For example, if the output says:
Please do the following to activate conda: > conda activate srw_appthen the user should run
conda activate srw_appto activate the workflow environment.Configure the experiment:
Copy the contents of the sample experiment from
config.community.yamltoconfig.yaml:cd ush cp config.community.yaml config.yamlUsers will need to open the
config.yamlfile and adjust the experiment parameters in it to suit the needs of their experiment (e.g., date, grid, physics suite). At a minimum, users need to modify theMACHINEparameter. In most cases, users will need to specify theACCOUNTparameter and the location of the experiment data (see Section 2.4.1 for Level 1 system default locations).For example, a user on Hercules (login node 1) might adjust or add the following fields to run the 12-hr “out-of-the-box” case on Hercules using prestaged system data and cron to automate the workflow:
user: MACHINE: hercules ACCOUNT: epic workflow: EXPT_SUBDIR: run_basic_srw USE_CRON_TO_RELAUNCH: true CRON_RELAUNCH_INTVL_MNTS: 3 task_get_extrn_ics: USE_USER_STAGED_EXTRN_FILES: true EXTRN_MDL_SOURCE_BASEDIR_ICS: /work/noaa/epic/role-epic/contrib/UFS_SRW_data/develop/input_model_data/FV3GFS/grib2/${yyyymmddhh} task_get_extrn_lbcs: USE_USER_STAGED_EXTRN_FILES: true EXTRN_MDL_SOURCE_BASEDIR_LBCS: /work/noaa/epic/role-epic/contrib/UFS_SRW_data/develop/input_model_data/FV3GFS/grib2/${yyyymmddhh}Users on a different system would update the machine, account, and data paths accordingly. Additional changes may be required based on the system and experiment. More detailed guidance is available in Section 2.4.3.2.2. Parameters and valid values are listed in Section 3.1.
Generate the experiment workflow.
./generate_FV3LAM_wflow.pyRun the workflow from the experiment directory (
$EXPTDIR). By default, the path to this directory is${EXPT_BASEDIR}/${EXPT_SUBDIR}(see Section 3.1.3.2 for more detail). There are several methods for running the workflow, which are discussed in Section 2.4.4. Most require the Rocoto Workflow Manager. For example, if the user automated the workflow using cron, run:cd $EXPTDIR rocotostat -w FV3LAM_wflow.xml -d FV3LAM_wflow.db -v 10The user can resubmit the
rocotostatcommand as needed to check the workflow progress.If the user has Rocoto but did not automate the workflow using cron, run:
cd $EXPTDIR ./launch_FV3LAM_wflow.shTo (re)launch the workflow and check the experiment’s progress, run:
./launch_FV3LAM_wflow.sh; tail -n 40 log.launch_FV3LAM_wflowThe workflow must be relaunched regularly and repeatedly until the log output includes a
Workflow status: SUCCESSmessage indicating that the experiment has finished.
Optionally, users may configure their own grid or vertical levels instead of using a predefined grid and default set of vertical levels. Users can also plot the output of their experiment(s) or run verification tasks using METplus.