docs: remove model-specific references from documentation

doc/.gitignore

@@ -4,3 +4,4 @@ source/Tools_api
 source/CIME_api
 source/_autosummary
 source/generated
+build/

doc/source/ccs/index.rst

@@ -18,7 +18,7 @@ The first thing to do is clone the model repository into ``$SRCROOT``.
 
 All examples will be run from ``$CIMEROOT`` which is should exist under ``$SRCROOT`` e.g. (``$CIMEROOT`` would be ``$SRCROOT/cime``).
 
-Next set the ``CIME_MODEL`` evnironment variable for your model, e.g. ``export CIME_MODEL=e3sm``.
+Next set the ``CIME_MODEL`` environment variable for your model, e.g. ``export CIME_MODEL=<model>``.
 
 .. note::
 

doc/source/ccs/model-configuration/support-a-new-machine.rst

@@ -68,10 +68,10 @@ As an example, on a MAC with 2 cores that has mpich with gnu fortran you would i
    > mpif90 fhello_world_mpi.F90 -o hello_world
    > mpirun -np 2 ./hello_world
 
-CESM Linux and Mac Support
+Linux and Mac Support
 ---------------------------
 
-The distribution of CESM includes machines called **homebrew** and **centos7-linux** in the file **$CIMEROOT/config/cesm/machines/config_machines.xml**.
+Your model distribution may include generic machine definitions (e.g., **homebrew** and **centos7-linux**) in the file **$CIMEROOT/config/$model/machines/config_machines.xml**.
 Please see the instructions in the file to create the directory structure and use these generic machine definitions.
 
 Steps for porting
@@ -85,7 +85,7 @@ Porting CIME involves several steps. The first step is to define your machine. Y
    In particular, you can create a **$HOME/.cime/config_machines.xml** file with the definition for your machine.
    A template to create this definition is provided in **$CIMEROOT/config/xml_schemas/config_machines_template.xml**. More details are provided in the template file.
    In addition, if you have a batch system, you will also need to add a **config_batch.xml** file to your **$HOME/.cime** directory.
-   All files in **$HOME/.cime/** are appended to the xml objects that are read into memory from the **$CIME/config/$model**, where **$model** is either ``e3sm`` or ``cesm``.
+   All files in **$HOME/.cime/** are appended to the xml objects that are read into memory from the **$CIME/config/$model** directory.
 
    .. note:: If you use method (2), you can download CIME updates without affecting your machine definitions in **$HOME/.cime**.
 
@@ -114,7 +114,7 @@ In what follows we outline the process for method (2) above:
 
 After running those steps correctly, you are ready to try a case at your target compset and resolution.
 
-Validating a CESM port with prognostic components
+Validating a port with prognostic components
 -------------------------------------------------
 
 The following port validation is recommended for any new machine.
@@ -133,15 +133,15 @@ possible.
 Users are responsible for their own validation process,
 especially with respect to science validation.
 
-These are the recommended steps for validating a port for the CESM model:
+These are the recommended steps for validating a port:
 
-1. Verify basic functionality of your port by performing the cheyenne "prealpha" tests on your machine. This can be done by issuing the following command:
+1. Verify basic functionality of your port by performing the "prealpha" tests on your machine. This can be done by issuing the following command:
 
    ::
 
-      ./create_test --xml-category prealpha --xml-machine cheyenne --xml-compiler intel --machine <your_machine_name> --compiler <your_compiler_name>
+      ./create_test --xml-category prealpha --xml-machine <reference_machine> --xml-compiler <reference_compiler> --machine <your_machine_name> --compiler <your_compiler_name>
 
-   This command will run the prealpha tests *defined* for cheyenne with the intel compiler, but will run them on *your* machine with *your* compiler.
+   This command will run the prealpha tests *defined* for the reference machine with the reference compiler, but will run them on *your* machine with *your* compiler.
    These tests will be run in the **$CIME_OUTPUT_ROOT**. To see the results of tests, you need to do the following:
 
    ::
@@ -153,11 +153,11 @@ These are the recommended steps for validating a port for the CESM model:
 2. Carry out ensemble consistency tests:
 
    This is described in ``$CIMEROOT/tools/statistical_ensemble_test/README``.
-   The CESM-ECT (CESM Ensemble Consistency Test) determines whether a new simulation set up (new machine, compiler, etc.) is statistically distinguishable from an accepted ensemble.
-   The ECT process involves comparing several runs (3) generated with the new scenario to an ensemble built on a trusted machine (currently cheyenne).
+   The Ensemble Consistency Test (ECT) determines whether a new simulation set up (new machine, compiler, etc.) is statistically distinguishable from an accepted ensemble.
+   The ECT process involves comparing several runs (3) generated with the new scenario to an ensemble built on a trusted machine.
    The python ECT tools are located in the pyCECT subdirectory ``$CIMEROOT/tools/statistical_ensemble_test/pyCECT``.
 
-   The verification tools in the CESM-ECT suite are:
+   The verification tools in the ECT suite are:
 
    ``CAM-ECT``: detects issues in CAM and CLM (12 month runs)
 
@@ -166,9 +166,8 @@ These are the recommended steps for validating a port for the CESM model:
    ``POP-ECT``: detects issues in POP and CICE (12 month runs)
 
    Follow the instructions in the **README** file to generate three ensemble runs for any of the above tests that are most relevant to your port.
-   Then please go to the `CESM2 ensemble verification website <http://www.cesm.ucar.edu/models/cesm2.0/verification>`_, where you can upload your files and subsequently obtain a quick response as to the success or failure of your verification.
 
-Performance tuning of a CESM port
+Performance tuning of a port
 -------------------------------------------------
 
 Once you have performed the verification that your port is successful,

doc/source/ccs/model-configuration/variables/compsets.rst

@@ -48,7 +48,7 @@ Every file listed in ``COMPSETS_SPEC_FILE`` will be searched to compile possible
 
 CIME will note which component's config_compsets.xml had the matching compset name and that component will be treated as
 the **primary component** As an example, the primary component for a compset that has a prognostic atmosphere,
-land and cice (in prescribed mode) and a data ocean is the atmosphere component (for cesm this is CAM) because the compset
+land and cice (in prescribed mode) and a data ocean is the atmosphere component (e.g. CAM in CESM) because the compset
 is defined, using the above example, in ``$SRCROOT/components/cam/cime_config/config_compsets.xml``
 In a compset where all components are prognostic, the primary component will be **allactive**.
 

doc/source/ccs/model-configuration/variables/grids.rst

@@ -387,14 +387,14 @@ The steps for adding a new component grid to the model system follow. This proce
    At this time, if you are running with a new ocean or runoff grid, please contact Michael Levy (mlevy_AT_ucar_DOT_edu) for assistance. If you are running with standard ocean and runoff grids, the mapping file should already exist and you do not need to generate it.
 
 
-6. CESM specific: If you are adding a new atmosphere grid, this means you are also generating a new land grid, and you will need to create a new CLM surface dataset. (Otherwise you can skip this step).
-   You need to first generate mapping files for CLM surface dataset (since this is a non-standard grid).
+6. If you are adding a new atmosphere grid, this means you are also generating a new land grid, and you may need to create a new land surface dataset. (Otherwise you can skip this step).
+   You need to first generate mapping files for the land surface dataset (since this is a non-standard grid).
    ::
 
       > cd $CIMEROOT/../components/clm/tools/mkmapdata
       > ./mkmapdata.sh --gridfile <lnd SCRIP grid file> --res <atm resolution name> --gridtype global
 
-    These mapping files are then used to generate CLM surface dataset. Below is an example for a current day surface dataset (model year 2000).
+    These mapping files are then used to generate the land surface dataset. Below is an example for a current day surface dataset (model year 2000).
 
     ::
 
@@ -403,7 +403,7 @@ The steps for adding a new component grid to the model system follow. This proce
 
 7. Create grid file needed for create_newcase.
    The next step is to add the necessary new entries in the appropriate ``config_grids.xml`` file.
-   You will need to modify ``$CIMEROOT/config/cesm/config_grids.xml`` or ``$CIMEROOT/config/e3sm/config_grids.xml`` depending on the value of ``$CIME_MODEL``.
+   You will need to modify ``$CIMEROOT/config/$model/config_grids.xml`` depending on the value of ``$CIME_MODEL``.
    You will need to:
 
    - add a single  ``<model_grid>`` entry

doc/source/ccs/model-configuration/variables/pes.rst

@@ -436,8 +436,8 @@ help determine the optimal load balance.
 Changing the pe layout of the model has NO IMPACT on the scientific
 results. The basic order of operations and calling sequence are
 hardwired into the driver and do not change with the pe
-layout. However, both CESM and E3SM do impose some contraints in the
-tempororal evolution of the components.  For example, the prognostic
+layout. However, models such as CESM and E3SM may impose some constraints in the
+temporal evolution of the components.  For example, the prognostic
 atmosphere model always run sequentially with the ice and land models
 for scientific reasons. As a result, running the atmosphere
 concurrently with the ice and land will result in idle processors at

doc/source/ccs/running-a-case.rst

@@ -19,6 +19,10 @@ Before submitting a case, it is a good idea to preview the run to ensure that th
 
 Example output:
 
+.. note::
+
+   The following is an example output. The specific paths, environment variables, and commands will vary depending on your model and machine configuration.
+
 .. code-block:: bash
 
   CASE INFO:
@@ -500,7 +504,7 @@ or a hybrid run or to back up to a previous restart date.
 Long-term Archiving
 ```````````````````
 Users may choose to follow their institution's preferred method for long-term
-archiving of model output. Previous releases of CESM provided an external
+archiving of model output. Previous releases of some CIME-driven models provided an external
 long-term archiver tool that supported mass tape storage and HPSS systems.
 However, with the industry migration away from tape archives, it is no longer
 feasible for CIME to support all the possible archival schemes available.
@@ -516,7 +520,7 @@ Scripts
 ```````
 Variables ``PRERUN_SCRIPT`` and ``POSTRUN_SCRIPT`` can each be used to name
 a script which should be executed immediately prior starting or
-following completion of the CESM executable within the batch
+following completion of the model executable within the batch
 environment.  The script is expected to be found in the case directory
 and will receive one argument which is the full path to that
 directory.  If the script is written in python and contains a

doc/source/ccs/setting-up-a-case.rst

@@ -238,85 +238,23 @@ The namelist file for DROF is ``drof_in`` (or ``drof_in_NNN`` for multiple insta
         ``chmod 644 user_drof.streams.txt[extension``
   3. Edit the **user_drof.streams.txt.*** file.
 
-.. TODO:: remove cesm specific docs
+Customizing active component-specific namelist settings
+-------------------------------------------------------
 
-Customizing CESM active component-specific namelist settings
-------------------------------------------------------------
+Active components typically provide a ``buildnml`` script in their ``cime_config`` directory that generates the component's namelist variables. Component-specific CIME xml variables are set in the component's ``config_component.xml`` file and are used by the ``buildnml`` script to generate the namelist.
 
-CAM
-```
+To modify an active component's namelist settings, add the appropriate keyword/value pair at the end of the **$CASEROOT/user_nl_<comp>** file, where ``<comp>`` is the component name. See the documentation at the top of each ``user_nl`` file for details.
 
-CIME calls **$SRCROOT/components/cam/cime_config/buildnml** to generate the CAM's namelist variables.
-
-CAM-specific CIME xml variables are set in **$SRCROOT/components/cam/cime_config/config_component.xml** and are used by CAM's **buildnml** script to generate the namelist.
-
-For complete documentation of namelist settings, see `CAM namelist variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/cam_nml.html>`_.
-
-To modify CAM namelist settings, add the appropriate keyword/value pair at the end of the **$CASEROOT/user_nl_cam** file. (See the documentation for each file at the top of that file.)
-
-For example, to change the solar constant to 1363.27, modify **user_nl_cam** file to contain the following line at the end:
+For example, to modify a namelist variable for an atmosphere component, edit the corresponding ``user_nl`` file:
 ::
 
- solar_const=1363.27
-
-To see the result, call ``preview_namelists`` and verify that the new value appears in **CaseDocs/atm_in**.
-
-CLM
-```
-
-CIME calls **$SRCROOT/components/clm/cime_config/buildnml** to generate the CLM namelist variables.
-
-CLM-specific CIME xml variables are set in **$SRCROOT/components/clm/cime_config/config_component.xml** and are used by CLM's **buildnml** script to generate the namelist.
-
-For complete documentation of namelist settings, see `CLM namelist variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/clm5_0_nml.html>`_.
-
-To modify CLM namelist settings, add the appropriate keyword/value pair at the end of the **$CASEROOT/user_nl_clm** file.
-
-To see the result, call ``preview_namelists`` and verify that the changes appear correctly in **CaseDocs/lnd_in**.
-
-MOSART
-``````
-
-CIME calls **$SRCROOT/components/mosart/cime_config/buildnml** to generate the MOSART namelist variables.
+ <variable_name>=<value>
 
-To modify MOSART namelist settings, add the appropriate keyword/value pair at the end of the **$CASEROOT/user_nl_rtm** file.
+To see the result, call ``preview_namelists`` and verify that the new value appears in the appropriate file under **CaseDocs/**.
 
-To see the result of your change, call ``preview_namelists`` and verify that the changes appear correctly in **CaseDocs/rof_in**.
-
-CICE
-````
-
-CIME calls **$SRCROOT/components/cice/cime_config/buildnml** to generate the CICE namelist variables.
-
-For complete documentation of namelist settings, see `CICE namelist variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/cice_nml.html>`_.
-
-To modify CICE namelist settings, add the appropriate keyword/value pair at the end of the **$CASEROOT/user_nl_cice** file.
-(See the documentation for each file at the top of that file.)
-To see the result of your change, call ``preview_namelists`` and verify that the changes appear correctly in **CaseDocs/ice_in**.
-
-In addition, ``case.setup`` creates CICE's compile time `block decomposition variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/cice_input.html>`_ in **env_build.xml**.
-
-POP2
-````
-
-CIME calls **$SRCROOT/components/pop2/cime_config/buildnml** to generate the POP2 namelist variables.
-
-For complete documentation of namelist settings, see `POP2 namelist variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/pop2_nml.html>`_.
-
-To modify POP2 namelist settings, add the appropriate keyword/value pair at the end of the **$CASEROOT/user_nl_pop2** file.
-(See the documentation for each file at the top of that file.)
-To see the result of your change, call ``preview_namelists`` and verify that the changes appear correctly in **CaseDocs/ocn_in**.
-
-CISM
-````
-
-See `CISM namelist variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/cism_nml.html>`_ for a complete description of the CISM runtime namelist variables. This includes variables that appear both in **cism_in** and in **cism.config**.
-
-To modify any of these settings, add the appropriate keyword/value pair at the end of the **user_nl_cism** file. (See the documentation for each file at the top of that file.)
-Note that there is no distinction between variables that will appear in **cism_in** and those that will appear in **cism.config**: simply add a new variable setting in **user_nl_cism**, and it will be added to the appropriate place in **cism_in** or **cism.config**.
-To see the result of your change, call ``preview_namelists`` and verify that the changes appear correctly in **CaseDocs/cism_in** and **CaseDocs/cism.config**.
+.. note::
 
-Some CISM runtime settings are sets via **env_run.xml**, as documented in `CISM runtime variables <https://www.cesm.ucar.edu/models/cesm2/settings/current/cism_input.html>`_.
+    Refer to your model's documentation for a complete list of namelist variables and their descriptions for each active component.
 
 Setting up the Case
 -------------------
@@ -359,6 +297,6 @@ Depends.*                       Lists of source code files that need special bui
 Macros.cmake                    File containing machine-specific makefile directives for your target platform/compiler. This file is created if it does not already exist. The user can modify the file to change certain aspects of the build, such as compiler flags. Running ``case.setup --clean`` will not remove the file once it has been created. However, if you remove or rename the Macros.make file, running ``case.setup`` recreates it.
 case.st_archive                 Script to perform short-term archiving to disk for your case output. Note that this script is run automatically by the normal CIME workflow.
 cmake_macros/                   Directory containing any CMake macros required for the machine/compiler combination.
-user_nl_xxx[_NNNN]              Files where all user modifications to component namelists are made. **xxx** is any one of the set of components targeted for the case. For example, for a full active CESM compset, **xxx** is cam, clm, or rtm, and so on. NNNN goes from 0001 to the number of instances of that component. (See :ref:`multiple instances<ccs-examples-multi-instance>`) For a case with 1 instance of each component (default), NNNN will not appear in the user_nl file names. A user_nl file of a given name is created only once. Calling ``case.setup --clean`` will *not remove* any user_nl files. Changing the number of instances in the **env_mach_pes.xml** file will cause only new user_nl files to be added to ``$CASEROOT``.
+user_nl_xxx[_NNNN]              Files where all user modifications to component namelists are made. **xxx** is any one of the set of components targeted for the case. For example, for a fully active compset, **xxx** could be the atmosphere, land, or river component name, and so on. NNNN goes from 0001 to the number of instances of that component. (See :ref:`multiple instances<ccs-examples-multi-instance>`) For a case with 1 instance of each component (default), NNNN will not appear in the user_nl file names. A user_nl file of a given name is created only once. Calling ``case.setup --clean`` will *not remove* any user_nl files. Changing the number of instances in the **env_mach_pes.xml** file will cause only new user_nl files to be added to ``$CASEROOT``.
 software_environment.txt        This file records some aspects of the computing system on which the case is built, such as the shell environment.
 =============================   ===============================================================================================================================

doc/source/ccs/timers.rst

@@ -56,6 +56,10 @@ The following describes the most important parts of this timing file:
 
 An example timing file of this type is:
 
+.. note::
+
+   The following is an example timing output. The specific machine, paths, compset, and component names will vary depending on your model and configuration.
+
 .. code-block:: text
 
    ---------------- TIMING PROFILE ---------------------