[develop] Rename variables related to GFDLgrid-type grids (#310)

## DESCRIPTION OF CHANGES: Rename experiment variables to match changes in PR #[787](ufs-community/regional_workflow#787) in `regional_workflow`. ## TESTS CONDUCTED: None needed. ## DEPENDENCIES: PR #[787](ufs-community/regional_workflow#787) in `regional_workflow`.
ufs-community · Jun 27, 2022 · 4bd21a5 · 4bd21a5
1 parent 1f3e2ac
commit 4bd21a5
Show file tree

Hide file tree

Showing 2 changed files with 28 additions and 25 deletions.
diff --git a/docs/UsersGuide/source/ConfigWorkflow.rst b/docs/UsersGuide/source/ConfigWorkflow.rst
@@ -3,7 +3,7 @@
 ============================================================================================
 Workflow Parameters: Configuring the Workflow in ``config.sh`` and ``config_defaults.sh``		
 ============================================================================================
-To create the experiment directory and workflow when running the SRW Application, the user must create an experiment configuration file named ``config.sh``. This file contains experiment-specific information, such as dates, external model data, observation data, directories, and other relevant settings. To help the user, two sample configuration files have been included in the ``regional_workflow`` repository’s ``ush`` directory: ``config.community.sh`` and ``config.nco.sh``. The first is for running experiments in community mode (``RUN_ENVIR`` set to "community"), and the second is for running experiments in "nco" mode (``RUN_ENVIR`` set to "nco"). Note that for this release, only "community" mode is supported. These files can be used as the starting point from which to generate a variety of experiment configurations for the SRW App.
+To create the experiment directory and workflow when running the SRW Application, the user must create an experiment configuration file named ``config.sh``. This file contains experiment-specific information, such as dates, external model data, observation data, directories, and other relevant settings. To help the user, two sample configuration files have been included in the ``regional_workflow`` repository's ``ush`` directory: ``config.community.sh`` and ``config.nco.sh``. The first is for running experiments in community mode (``RUN_ENVIR`` set to "community"), and the second is for running experiments in "nco" mode (``RUN_ENVIR`` set to "nco"). Note that for this release, only "community" mode is supported. These files can be used as the starting point from which to generate a variety of experiment configurations for the SRW App.
 
 There is an extensive list of experiment parameters that a user can set when configuring the experiment. Not all of these need to be explicitly set by the user in ``config.sh``. If a user does not define an entry in the ``config.sh`` script, either its value in ``config_defaults.sh`` will be used, or it will be reset depending on other parameters, such as the platform on which the experiment will be run (specified by ``MACHINE``). Note that ``config_defaults.sh`` contains the full list of experiment parameters that a user may set in ``config.sh`` (i.e., the user cannot set parameters in ``config.sh`` that are not initialized in ``config_defaults.sh``).
 
@@ -677,27 +677,30 @@ The following parameters must be set if using the "GFDLgrid" method to generate
 ``GFDLgrid_LAT_T6_CTR``: (Default: "")
    Latitude of the center of tile 6 (in degrees).
 
-``GFDLgrid_RES``: (Default: "")
-   Number of points in either of the two horizontal directions (x and y) on each tile of the parent global cubed-sphere grid. Valid values: ``"48"`` | ``"96"`` | ``"192"`` | ``"384"`` | ``"768"`` | ``"1152"`` | ``"3072"``
+``GFDLgrid_NUM_CELLS``: (Default: "")
+   Number of grid cells in either of the two horizontal directions (x and y) on each of the six tiles of the parent global cubed-sphere grid. Valid values: ``"48"`` | ``"96"`` | ``"192"`` | ``"384"`` | ``"768"`` | ``"1152"`` | ``"3072"``
 
-   .. note::
-      ``GFDLgrid_RES`` is a misnomer because it specifies *number* of grid cells, not grid size (in meters or kilometers). However, we keep this name in order to remain consistent with the usage of the word "resolution" in the global forecast model and auxiliary codes. The mapping from ``GFDLgrid_RES`` to a nominal resolution (grid cell size) for several values of ``GFDLgrid_RES`` is as follows (assuming a uniform global grid, i.e., with Schmidt stretch factor of 1: ``GFDLgrid_STRETCH_FAC="1"``):
-
-         +----------------+--------------------+
-         | GFDLgrid_RES   | typical cell size  |
-         +================+====================+
-         | 192            |      50 km         |
-         +----------------+--------------------+
-         | 384            |      25 km         |
-         +----------------+--------------------+
-         | 768            |      13 km         |
-         +----------------+--------------------+
-         | 1152           |      8.5 km        |
-         +----------------+--------------------+
-         | 3072           |      3.2 km        |
-         +----------------+--------------------+
-
-      Note that these are only typical cell sizes. The actual cell size on the global grid tiles varies somewhat as we move across a tile.
+   To give an idea of what these values translate to in terms of grid cell size in kilometers, we list below the approximate grid cell size on a uniform global grid having the specified value of ``GFDLgrid_NUM_CELLS``, where by "uniform" we mean with Schmidt stretch factor ``GFDLgrid_STRETCH_FAC="1"`` (although in regional applications ``GFDLgrid_STRETCH_FAC`` will typically be set to a value greater than ``"1"`` to obtain a smaller grid size on tile 6):
+
+         +---------------------+--------------------+
+         | GFDLgrid_NUM_CELLS  | typical cell size  |
+         +=====================+====================+
+         |  48                 |     208 km         |
+         +---------------------+--------------------+
+         |  96                 |     104 km         |
+         +---------------------+--------------------+
+         | 192                 |      52 km         |
+         +---------------------+--------------------+
+         | 384                 |      26 km         |
+         +---------------------+--------------------+
+         | 768                 |      13 km         |
+         +---------------------+--------------------+
+         | 1152                |      8.7 km        |
+         +---------------------+--------------------+
+         | 3072                |      3.3 km        |
+         +---------------------+--------------------+
+
+      Note that these are only typical cell sizes. The actual cell size on the global grid tiles varies somewhat as we move across a tile (and is dependent on ``GFDLgrid_STRETCH_FAC``).
 
 
 ``GFDLgrid_STRETCH_FAC``: (Default: "")
@@ -718,8 +721,8 @@ The following parameters must be set if using the "GFDLgrid" method to generate
 ``GFDLgrid_JEND_OF_RGNL_DOM_ON_T6G``: (Default: "")
    j-index on tile 6 at which the regional grid (tile 7) ends.
 
-``GFDLgrid_USE_GFDLgrid_RES_IN_FILENAMES``: (Default: "")
-   Flag that determines the file naming convention to use for grid, orography, and surface climatology files (or, if using pregenerated files, the naming convention that was used to name these files).  These files usually start with the string ``"C${RES}_"``, where ``RES`` is an integer. In the global forecast model, ``RES`` is the number of points in each of the two horizontal directions (x and y) on each tile of the global grid (defined here as ``GFDLgrid_RES``). If this flag is set to "TRUE", ``RES`` will be set to ``GFDLgrid_RES`` just as in the global forecast model. If it is set to "FALSE", we calculate (in the grid generation task) an "equivalent global uniform cubed-sphere resolution" --- call it ``RES_EQUIV`` --- and then set ``RES`` equal to it. ``RES_EQUIV`` is the number of grid points in each of the x and y directions on each tile that a global uniform cubed-sphere grid (i.e., stretch factor of 1) would need to have in order to have the same average grid size as the regional grid. This is a more useful indicator of the grid size because it takes into account the effects of ``GFDLgrid_RES``, ``GFDLgrid_STRETCH_FAC``, and ``GFDLgrid_REFINE_RATIO`` in determining the regional grid's typical grid size, whereas simply setting RES to ``GFDLgrid_RES`` doesn't take into account the effects of ``GFDLgrid_STRETCH_FAC`` and ``GFDLgrid_REFINE_RATIO`` on the regional grid's resolution. Nevertheless, some users still prefer to use ``GFDLgrid_RES`` in the file names, so we allow for that here by setting this flag to "TRUE".
+``GFDLgrid_USE_NUM_CELLS_IN_FILENAMES``: (Default: "")
+   Flag that determines the file naming convention to use for grid, orography, and surface climatology files (or, if using pregenerated files, the naming convention that was used to name these files).  These files usually start with the string ``"C${RES}_"``, where ``RES`` is an integer. In the global forecast model, ``RES`` is the number of points in each of the two horizontal directions (x and y) on each tile of the global grid (defined here as ``GFDLgrid_NUM_CELLS``). If this flag is set to "TRUE", ``RES`` will be set to ``GFDLgrid_NUM_CELLS`` just as in the global forecast model. If it is set to "FALSE", we calculate (in the grid generation task) an "equivalent global uniform cubed-sphere resolution" -- call it ``RES_EQUIV`` -- and then set ``RES`` equal to it. ``RES_EQUIV`` is the number of grid points in each of the x and y directions on each tile that a global UNIFORM (i.e., stretch factor of 1) cubed-sphere grid would need to have in order to have the same average grid size as the regional grid. This is a more useful indicator of the grid size because it takes into account the effects of ``GFDLgrid_NUM_CELLS``, ``GFDLgrid_STRETCH_FAC``, and ``GFDLgrid_REFINE_RATIO`` in determining the regional grid's typical grid size, whereas simply setting ``RES`` to ``GFDLgrid_NUM_CELLS`` doesn't take into account the effects of ``GFDLgrid_STRETCH_FAC`` and ``GFDLgrid_REFINE_RATIO`` on the regional grid's resolution. Nevertheless, some users still prefer to use ``GFDLgrid_NUM_CELLS`` in the file names, so we allow for that here by setting this flag to "TRUE".
 
 Computational Forecast Parameters
 =================================
@@ -1271,7 +1274,7 @@ Ensemble Model Parameters
 Halo Blend Parameter
 ====================
 ``HALO_BLEND``: (Default: "10")
-   Number of cells to use for “blending” the external solution (obtained from the :term:`LBCs`) with the internal solution from the FV3LAM :term:`dycore`. Specifically, it refers to the number of rows into the computational domain that should be blended with the LBCs. Cells at which blending occurs are all within the boundary of the native grid; they don’t involve the 4 cells outside the boundary where the LBCs are specified (which is a different :term:`halo`). Blending is necessary to smooth out waves generated due to mismatch between the external and internal solutions. To shut :term:`halo` blending off, set this to zero. 
+   Number of cells to use for "blending" the external solution (obtained from the :term:`LBCs`) with the internal solution from the FV3LAM :term:`dycore`. Specifically, it refers to the number of rows into the computational domain that should be blended with the LBCs. Cells at which blending occurs are all within the boundary of the native grid; they don't involve the 4 cells outside the boundary where the LBCs are specified (which is a different :term:`halo`). Blending is necessary to smooth out waves generated due to mismatch between the external and internal solutions. To shut :term:`halo` blending off, set this to zero. 
 
 
 FVCOM Parameter

diff --git a/docs/UsersGuide/source/WE2Etests.rst b/docs/UsersGuide/source/WE2Etests.rst
@@ -56,7 +56,7 @@ Users may specify the set of tests to run by creating a text file, such as ``my_
    cat > my_tests.txt
    custom_ESGgrid
    grid_RRFS_CONUScompact_25km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v16
- 
+
 
 (and ``Ctrl + D`` to exit). For each test in ``my_tests.txt``, ``run_WE2E_tests.sh`` will generate a new experiment directory and, by default, create a new :term:`cron` job in the user's cron table that will (re)launch the workflow every 2 minutes. This cron job calls the workflow launch script ``launch_FV3LAM_wflow.sh`` until the workflow either completes successfully (i.e., all tasks are successful) or fails (i.e., at least one task fails). 
 The cron job is then removed from the user's cron table.