[master] Updating documentation from release branch with some minor f…

…ixes, add Cheyenne workflow file (#130)

* Bring over documentation from release branch

* Bring over cheyenne workflow file from release branch

* Users guide spelling fixes from Jamie

* A few more spelling fixes, capitalization consistency in Users Guide

* Fix some merge weirdness in docs/INSTALL

* Remove SystemRequirements.rst which is no longer needed (incorporated into another chapter)

docs/UsersGuide/requirements.txt

@@ -1 +1,2 @@
-sphinxcontrib-bibtex<2.0.0
+sphinxcontrib-bibtex
+sphinx_rtd_theme

docs/UsersGuide/source/FAQ.rst

@@ -4,10 +4,88 @@
 FAQ
 ***
 
-=======================================================
-How to turn On/Off the Cycle-Independent Workflow Tasks
-=======================================================
+=========================================================
+How do I turn On/Off the Cycle-Independent Workflow Tasks
+=========================================================
+The first three pre-processing tasks ``make_grid``, ``make_orog``, and ``make_sfc_climo``
+are cycle-independent, meaning that they only need to be run once per experiment. If the
+grid, orography, and surface climatology files that these tasks generate are already 
+available (e.g. from a previous experiment that used the same grid as the current), then
+these tasks can be skipped by having the workflow use those pre-generated files.  This 
+can be done by adding the following lines to the ``config.sh`` script before running 
+the ``generate_FV3LAM_wflow.sh`` script:
+
+.. code-block:: console
+
+   RUN_TASK_MAKE_GRID=”FALSE”
+   GRID_DIR=”/path/to/directory/containing/grid/files”
+   RUN_TASK_MAKE_OROG=”FALSE”
+   OROG_DIR=”/path/to/directory/containing/orography/files”
+   RUN_TASK_MAKE_SFC_CLIMO=”FALSE”
+   SFC_CLIMO_DIR=”/path/to/directory/containing/surface/climatology/files”
+
+The ``RUN_TASK_MAKE_GRID``, ``RUN_TASK_MAKE_OROG``, and ``RUN_TASK_MAKE_SFC_CLIMO`` flags
+disable their respective tasks, and ``GRID_DIR``, ``OROG_DIR``, and ``SFC_CLIMO_DIR``
+specify the directories in which the workflow can find the pre-generated grid, orography,
+and surface climatology files, respectively (these directories may be the same, i.e. all
+three sets of files may be placed in the same location).  By default, the ``RUN_TASK_MAKE_...`` 
+flags are set to ``TRUE`` in ``config_defaults.sh``, i.e. the workflow will by default 
+run the ``make_grid``, ``make_orog``, and ``make_sfc_climo`` tasks.
+
+===================================
+How do I define an experiment name?
+===================================
+The name of the experiment is set in the ``config.sh`` file using the variable ``EXPT_SUBDIR``.
+See :numref:`Section %s <SetUpConfigFile>` for more details.
+
+================================================
+How do I change the Suite Definition File (SDF)?
+================================================
+The SDF is set in the ``config.sh`` file using the variable ``CCPP_PHYS_SUITE``.  When the
+``generate_FV3LAM_wflow.sh`` script is run, the SDF file is copied from its location in the forecast
+model directory to the experiment directory ``EXPTDIR``.
+
+=============================
+How do I restart a DEAD task?
+=============================
+On platforms that utilize Rocoto workflow software (such as NCAR’s Cheyenne machine), sometimes if
+something goes wrong with the workflow a task may end up in the DEAD state:
+
+.. code-block:: console
+
+   rocotostat -w FV3SAR_wflow.xml -d FV3SAR_wflow.db -v 10
+          CYCLE            TASK        JOBID    STATE    EXIT STATUS  TRIES DURATION
+   =================================================================================
+   201905200000       make_grid      9443237   QUEUED              -      0      0.0
+   201905200000       make_orog            -        -              -      -        -
+   201905200000  make_sfc_climo            -        -              -      -        -
+   201905200000   get_extrn_ics      9443293     DEAD            256      3      5.0
+
+This means that the dead task has not completed successfully, so the workflow has stopped. Once the issue
+has been identified and fixed (by referencing the log files), the failed task can re-run using the ``rocotorewind``
+command:
+
+.. code-block:: console
+
+   rocotorewind -w FV3SAR_wflow.xml -d FV3SAR_wflow.db -v 10 -c 201905200000 -t get_extrn_ics
+
+where ``-c`` specifies the cycle date (first column of rocotostat output) and ``-t`` represents the task name
+(second column of rocotostat output).  After using ``rocotorewind``, the next time ``rocotorun`` is used to
+advance the workflow, the job will be resubmitted.
+
+===========================
+How do I change the grid?
+===========================
+To change the predefined grid, you need to modify the ``PREDEF_GRID_NAME`` variable in the
+``config.sh`` script which the user has created to generate an experiment configuration and workflow.
+Users can choose from one of three predefined grids for the SRW Application:
+
+.. code-block:: console
+
+   RRFS_CONUS_3km
+   RRFS_CONUS_13km
+   RRFS_CONUS_25km
+
+An option also exists to create a user-defined grid, with information available in
+:numref:`Chapter %s <LAMGrids>`.
 
-================================
-How to define an experiment name
-================================

docs/UsersGuide/source/Glossary.rst

@@ -7,50 +7,64 @@ Glossary
 .. glossary::
 
    CCPP
-      Model agnostic, vetted, collection of codes containing atmospheric physical parameterizations
-      and suites for use in NWP along with a framework that connects the physics to host models
+      A forecast-model agnostic, vetted collection of codes containing atmospheric physical 
+      parameterizations and suites of parameterizations for use in Numerical Weather Prediction 
+      (NWP) along with a framework that connects the physics to the host forecast model.
 
    chgres_cube
-       The preprocessing software used to create initial condition files to “coldstart” the forecast
-       model. The initial conditions are created from either GFS GRIB2 or NEMSIO data.
+       The preprocessing software used to create initial and boundary condition files to 
+       “coldstart” the forecast model.
 
    FV3
-      The GFDL Finite-Volume Cubed-Sphere Dynamical Core (FV3) is a scalable and flexible dynamical
-      core capable of both hydrostatic and non-hydrostatic atmospheric simulations.
+      The Finite-Volume Cubed-Sphere dynamical core (dycore). Developed at NOAA's Geophysical 
+      Fluid Dynamics Laboratory (GFDL), it is a scalable and flexible dycore capable of both 
+      hydrostatic and non-hydrostatic atmospheric simulations.  It is the dycore used in the 
+      UFS Weather Model.
+
+   GRIB2 
+      The second version of the World Meterological Organization's (WMO) standard for distributing gridded data.  
 
    NCEP
-      National Centers for Environmental Prediction, an arm of the National Weather Service.
+      National Centers for Environmental Prediction, an arm of the National Weather Service,
+      consisting of nine centers.  More information can be found at https://www.ncep.noaa.gov.
 
    NCEPLIBS
-      The NCEP library source code and utilities required for chgres_cube, the UFS Weather Model, and UPP.
+      The software libraries created and maintained by :term:`NCEP` that are required for running 
+      :term:`chgres_cube`, the UFS Weather Model, and :term:`UPP`.
 
    NCEPLIBS-external
-      A collection of third-party libraries required to build NCEPLIBS, chgres_cube, the UFS Weather Model, and UPP.
+      A collection of third-party libraries required to build :term:`NCEPLIBS`, :term:`chgres_cube`, 
+      the UFS Weather Model, and :term:`UPP`.
 
    NCL
-      An interpreted language designed specifically for scientific data analysis and visualization.
-      More information can be found at https://www.ncl.ucar.edu.
+      An interpreted programming language designed specifically for scientific data analysis and 
+      visualization.  More information can be found at https://www.ncl.ucar.edu.
 
    NEMS
-      The NOAA Environmental Modeling System - a software infrastructure that supports
-      NCEP/EMC’s forecast products.
+      The NOAA Environmental Modeling System is a common modeling framework whose purpose is 
+      to streamline components of operational modeling suites at :term:`NCEP`.
 
    NEMSIO
-      A binary format for atmospheric model output on the native gaussian grid.
+      A binary format for atmospheric model output from :term:`NCEP`'s Global Forecast System (GFS).
 
    UFS
-      A Unified Forecast System (UFS) is a community-based, coupled comprehensive Earth
-      system modeling system. The UFS numerical applications span local to global domains
-      and predictive time scales from sub-hourly analyses to seasonal predictions. It is
-      designed to support the Weather Enterprise and to be the source system for NOAA's
-      operational numerical weather prediction applications
+      The Unified Forecast System is a community-based, coupled comprehensive Earth modeling 
+      system consisting of several applications (apps). These apps span regional to global 
+      domains and sub-hourly to seasonal time scales. The UFS is designed to support the Weather 
+      Enterprise and to be the source system for NOAA's operational numerical weather prediction 
+      applications.  More information can be found at http://ufs-dev.rap.ucar.edu/index.html.
+
+   UFS_UTILS
+      A collection of codes used by multiple :term:`UFS` apps (e.g. the UFS Short-Range Weather App,
+      the UFS Medium-Range Weather App). The grid, orography, surface climatology, and initial 
+      and boundary condition generation codes used by the UFS Short-Range Weather App are all 
+      part of this collection.
 
    UPP
-      The Unified Post Processing System, developed at NCEP and used operationally for models
-      maintained by NCEP. The UPP has the capability to post-process output from a variety of NWP
-      models, including FV3.
+      The Unified Post Processor is software developed at :term:`NCEP` and used operationally to 
+      post-process raw output from a variety of :term:`NCEP`'s NWP models, including the FV3.
 
    Weather Model
       A prognostic model that can be used for short- and medium-range research and
-      operational forecasts. It can be an atmosphere-only model or be an atmospheric
+      operational forecasts. It can be an atmosphere-only model or an atmospheric
       model coupled with one or more additional components, such as a wave or ocean model.