WCD-10. A Community Workflow for the Limited Area Model (LAM) Configuration of the FV3

Abstract
We present various aspects and features of a community workflow being developed by the DTC (Developmental Testbed Center, a collaboration between NOAA’s GSL and NCAR) for running the community version of the FV3 (Finite Volume Cubed Sphere) atmosphere model in its limited-area-model (LAM) configuration. This work is part of a multi-center/NOAA lab effort (GSL, EMC, NSSL, and NCAR) to develop an FV3-LAM that will be accessible to and usable by the wider research community. The set of experiment and workflow generation scripts are easily configurable and include extensive error and compatibility checks to inform the user of inconsistent configurations before any forecasts are launched. The capabilities of the community workflow thus far include: (1) generation of arbitrary or predefined regional domains with nearly-uniform grids [e.g. contiguous US domain with 3km cells (HRRR-like), North American domain with 13km cells (RAP-like), Alaska domain with 3km cells]; (2) generation of filtered topography on such domains/grids; (3) generation of climatological fields on these grids; (4) generation of initial conditions (ICs), surface fields, and lateral boundary conditions (LBCs) from any one of several external NWP models (e.g. FV3GFS, GSMGFS, RAPX, HRRRX, NAM), with the option to use a different external model for the ICs than for the LBCs; (5) fetching of external model files from default system directories, user-specified staging directories, mass store, or NOMADS (NOAA Operational Model Archive and Distribution System); (6) use of various physics suites available in the ufs-weather-model github repository (which couples the FV3 dycore with the Common Community Physics Package (CCPP)); (7) running of ensemble forecasts; (8) outputting of fields on either the native FV3-LAM grid or on grids supported by EMC's write-component regridding utility (e.g. rotated lat-lon, Lambert conformal); (9) post-processing of output using the Unified Post Processor (UPP); (10) testing infrastructure to ensure that new workflow features behave as expected and do not break existing functionality; (11) script structure that complies with operational (NCO) standards, e.g .use of J-jobs, ex-scripts, directory structure, and naming conventions; (12) running of experiments with or without the rocoto workflow manager; (13) running of experiments on various NOAA HPC machines, NCAR machines (e.g. Cheyenne), and generic platforms; and (14) plotting scripts for verifying configuration, grids, inputs, and outputs. The workflow is accompanied by detailed documentation to allow users to easily configure and run experiments without having to understand the various model components in detail. It can be obtained by following the instructions at the UFS Short-Range Weather Application’s umbrella repository’s URL at https://github.com/ufs-community/ufs-srweather-app.