diff --git a/doc/UsersGuide/source/Acronyms.rst b/doc/UsersGuide/source/Acronyms.rst index d529e7cf4f..edf950688d 100644 --- a/doc/UsersGuide/source/Acronyms.rst +++ b/doc/UsersGuide/source/Acronyms.rst @@ -8,7 +8,7 @@ Acronyms :widths: 20 80 +----------------+---------------------------------------------------+ - | Abbreviation | Explanation | + | Acronyms | Explanation | +================+===================================================+ | AOML | NOAA's Atlantic Oceanographic and Meteorological | | | Laboratory | @@ -19,8 +19,6 @@ Acronyms +----------------+---------------------------------------------------+ | CCPP | Common Community Physics Package | +----------------+---------------------------------------------------+ - | CPP | C preprocessor | - +----------------+---------------------------------------------------+ | dycore | Dynamical core | +----------------+---------------------------------------------------+ | EDMF | Eddy-Diffusivity Mass Flux | @@ -29,13 +27,13 @@ Acronyms +----------------+---------------------------------------------------+ | ESMF | The Earth System Modeling Framework | +----------------+---------------------------------------------------+ - | ESRL | NOAA Earth System Research Laboratory | + | ESRL | NOAA Earth System Research Laboratories | +----------------+---------------------------------------------------+ | FMS | Flexible Modeling System | +----------------+---------------------------------------------------+ | FV3 | Finite-Volume Cubed Sphere | +----------------+---------------------------------------------------+ - | GFDL | Geophysical Fluid Dynamics Laboratory | + | GFDL | NOAA Geophysical Fluid Dynamics Laboratory | +----------------+---------------------------------------------------+ | GFS | Global Forecast System | +----------------+---------------------------------------------------+ @@ -51,26 +49,16 @@ Acronyms +----------------+---------------------------------------------------+ | NCEP | National Centers for Environmental Predicction | +----------------+---------------------------------------------------+ - | NEMS | National Oceanic and Atmospheric Administration | - | | (NOAA) Environmental Modeling System | + | NEMS | NOAA Environmental Modeling System | +----------------+---------------------------------------------------+ | NOAA | National Oceanic and Atmospheric Administration | +----------------+---------------------------------------------------+ | NSSL | National Severe Storms Laboratory | +----------------+---------------------------------------------------+ - | OpenMP | Open Multi-Processing | - +----------------+---------------------------------------------------+ | PBL | Planetary Boundary Layer | +----------------+---------------------------------------------------+ - | png | Portable Network Graphic | - +----------------+---------------------------------------------------+ | PR | Pull request | +----------------+---------------------------------------------------+ - | PROD | Compiler optimization flags for production mode | - +----------------+---------------------------------------------------+ - | REPRO | Compiler optimization flags for reproduction mode | - | | (bit-for-bit testing) | - +----------------+---------------------------------------------------+ | RRTMG | Rapid Radiative Transfer Model for Global | | | Circulation Models | +----------------+---------------------------------------------------+ @@ -92,7 +80,5 @@ Acronyms +----------------+---------------------------------------------------+ | UFS | Unified Forecast System | +----------------+---------------------------------------------------+ - | VLab | Virtual Laboratory | - +----------------+---------------------------------------------------+ | WM | Weather Model | +----------------+---------------------------------------------------+ diff --git a/doc/UsersGuide/source/BuildingAndRunning.rst b/doc/UsersGuide/source/BuildingAndRunning.rst index f6b96241a2..5a0ec2c2df 100644 --- a/doc/UsersGuide/source/BuildingAndRunning.rst +++ b/doc/UsersGuide/source/BuildingAndRunning.rst @@ -1,5 +1,5 @@ .. _BuildingAndRunning: - + ****************************************** Building and Running the UFS Weather Model ****************************************** @@ -15,8 +15,8 @@ There are two categories of libraries that are needed: Most have an NCEPLIBS prefix in the repository, e.g. NCEPLIBS-bacio. Select tools from the UFS Utilities repository (UFS-UTILS) are also included in this category. A list of the bundled libraries tested with this WM release is in the top-level ``README`` of the `NCEPLIBS repository - `_. Be sure to look at the tag in that repository that - matches the tag on this WM release. + `_ (**be sure to look at the tag in that repository that + matches the tag on this WM release**). #. Third-party libraries (NCEPLIBS-external). These are libraries that were developed external to the UFS Weather Model. They are general software packages that are also used by other models in @@ -42,7 +42,7 @@ WORK directory path before you get started. If your platform is not included in these platform- and compiler-specific ``README`` files, there is a more generic set of instructions in the ``README`` file at the top level of the `NCEPLIBS-external repository -`_, and at the top level of the `NCEPLIBS repository +`_, and at the top level of the `NCEPLIBS repository `_. It may still be a good idea to look at some of the platform- and compiler-specific ``README`` files as a guide. Again, be sure to use the tag that corresponds to this version of the WM. @@ -62,7 +62,7 @@ You will need to make sure that the WM has the paths to the libraries that it re that, these environment variables need to be set, as shown in :numref:`Table %s ` and :numref:`Table %s ` for the bash shell. -.. _ReqLibEnvVar: +.. _ReqLibEnvVar: .. table:: *Bundled libraries (NCEPLIBS) required for the Weather Model* @@ -84,7 +84,7 @@ that, these environment variables need to be set, as shown in :numref:`Table %s | -.. _ReqLibEnvVar2: +.. _ReqLibEnvVar2: .. table:: *Third-party libraries (NCEPLIBS-external) required for the Weather Model* @@ -110,11 +110,11 @@ load the modules, for example on hera, run: cd ../.. If you are not running on one of the pre-configured platforms, you will need to set the environment variables -in a different way. +in a different way. If you used one of the platform- and compiler-specific ``README`` files in the ``doc/`` directory of NCEPLIBS-external to build the prerequisite libraries, there is a script in the ``NCEPLIBS-ufs-v1.0.0/bin`` directory called -``setenv_nceplibs.sh`` that will set the NCEPLIBS-external variables for you. +``setenv_nceplibs.sh`` that will set the NCEPLIBS-external variables for you. Of course, you can also set the values of these variables yourself if you know where the paths are on your system. @@ -122,14 +122,14 @@ Of course, you can also set the values of these variables yourself if you know w Setting other environment variables ----------------------------------- You will also need to set the ``CMAKE_Platform`` environment variable. -See the ``README`` files in the ``doc/`` directories of the NCEPLIBS-external repository for recognized values. +See the ``README`` files in the ``doc/`` directories of the NCEPLIBS-external repository for recognized values. The default value is: .. code-block:: console export CMAKE_Platform=linux. - + Where is either Intel or GNU. You may also wish to set the following environment variables: * ``CMAKE_Platform``: if not set the default is linux.${COMPILER} @@ -151,7 +151,7 @@ If ``CCPP_SUITES`` is not set, the default is ``‘FV3_GFS_v15p2’``. Building the model ------------------ The UFS Weather Model uses the cmake build system. There is a build script called ``build.sh`` in the -top-level directory of the WM repository that ensures all necessary variables are actually set. +top-level directory of the WM repository that ensures all necessary variables are actually set. After setting all the environment variables, you can build the model using @@ -168,5 +168,4 @@ set up specifically for issues related to the Weather Model. Running the model ================= The `UFS Weather Model wiki `_ includes a simple -test case that illustrates how the model can be run. - +test case that illustrates how the model can be run. diff --git a/doc/UsersGuide/source/ContributingDevelopment.rst b/doc/UsersGuide/source/ContributingDevelopment.rst index 4eebececb0..330aaa9ee6 100644 --- a/doc/UsersGuide/source/ContributingDevelopment.rst +++ b/doc/UsersGuide/source/ContributingDevelopment.rst @@ -1,5 +1,5 @@ .. _ContributingDevelopment: - + ************************* Contributing Development ************************* @@ -20,7 +20,7 @@ If developers would like to get their code committed back to the original reposi * Merge developer’s branch to the latest ufs-weather-model develop branch in authoritative repository. If changes are made in model sub-components, developers need to merge their branches to branches with the corresponding authoritative repository (or original repository for some components). For this, code management practices of the subcomponents need to be followed. - * Regression tests associated with the ufs-weather-model are available on Tier 1 and Tier 2 platforms as described in https://github.com/ufs-community/ufs-weather-model/wiki/Weather-Model-Platform-and-Compiler-Support. If the developer has access to these platforms, the developer should pass the regression test on at least one supported platform. If the developer does not have access to these platforms, this should be stated in the PR so the code manager(s) can conduct the tests. + * Regression tests associated with the ufs-weather-model are available on Tier 1 and Tier 2 platforms as described in https://github.com/ufs-community/ufs-weather-model/wiki/Regression-Test-Policy-for-Weather-Model-Platforms-and-Compilers. If the developer has access to these platforms, the developer should pass the regression test on at least one supported platform. If the developer does not have access to these platforms, this should be stated in the PR so the code manager(s) can conduct the tests. * For each component branch where developers make changes, developers need to go to their personal fork on GitHub and click on the “New pull request” button. When a new page “Compare changes” appears, developers will choose the branch in their fork with code changes to commit and the branch in upstream repository that the changes will be committed to. Also developers in the commit comment must add the github issue title and number created in 1) in the comment box. The code differences between the two branches will be displayed. Developers can review the differences and click on “submit pull request” to make the pull request. After code changes are committed to the component repository, developers will make pull requests to ufs-weather-model repository. @@ -85,7 +85,7 @@ rt.sh is a bash shell file to run the RT and has the following options: % cd ufs-weather-model/tests % ./rt.sh -f -This command can only be used on platforms that have been configured for regression testing (Tier 1 and Tier 2 platforms as described in https://github.com/ufs-community/ufs-weather-model/wiki/Weather-Model-Platform-and-Compiler-Support). For information on testing the CCPP code, or using alternate computational platforms, see the following sections. +This command can only be used on platforms that have been configured for regression testing (Tier 1 and Tier 2 platforms as described in https://github.com/ufs-community/ufs-weather-model/wiki/Regression-Test-Policy-for-Weather-Model-Platforms-and-Compilers). For information on testing the CCPP code, or using alternate computational platforms, see the following sections. This command and all others below produce log output in ./tests/log_machine.compiler. These log files contain information on the location of the run directories that can be used as templates for the user. Each rt*.conf contains one or more compile commands preceding a number of tests. diff --git a/doc/UsersGuide/source/FAQforModelConfiguration.rst b/doc/UsersGuide/source/FAQforModelConfiguration.rst deleted file mode 100644 index 4467732fe3..0000000000 --- a/doc/UsersGuide/source/FAQforModelConfiguration.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. _FAQforModelConfiguration: - -*************************** -FAQ for Model Configuration -*************************** - -* How do I add a new field to the output file? - -* What is a “cold start” and a “warm start”? - -* How do I restart the model? - diff --git a/doc/UsersGuide/source/Glossary.rst b/doc/UsersGuide/source/Glossary.rst index b01d440a61..17267c64cf 100644 --- a/doc/UsersGuide/source/Glossary.rst +++ b/doc/UsersGuide/source/Glossary.rst @@ -10,11 +10,11 @@ Glossary 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 - *CCPP-Framework* + CCPP-Framework The infrastructure that connects physics schemes with a host model; also refers to a software repository of the same name - *CCPP-Physics* + CCPP-Physics The pool of CCPP-compliant physics schemes; also refers to a software repository of the same name FMS @@ -38,17 +38,6 @@ Glossary oversimplified parameters, rather than realistically requiring such effects to be consequences of the dynamics of the system (AMS Glossary) - Physics *cap* - Autogenerated interface between an individual physics scheme and the host model. Used - only in the dynamic CCPP build - - PROD - Compiler flags used by NCEP for operational runs of the UFS Atmosphere and by EMC for - regression tests of the code - - REPRO - Compiler flags used by EMC to guarantee reproducibility of the UFS Atmosphere code - Suite Definition File (SDF) An external file containing information about the construction of a physics suite. It describes the schemes that are called, in which diff --git a/doc/UsersGuide/source/InputsOutputs.rst b/doc/UsersGuide/source/InputsOutputs.rst index 5ec4e46c53..910ebdf116 100644 --- a/doc/UsersGuide/source/InputsOutputs.rst +++ b/doc/UsersGuide/source/InputsOutputs.rst @@ -1,10 +1,10 @@ .. _InputsOutputs: - + ************************* Inputs and Outputs ************************* -This chapter describes the input and output files needed for executing the model in the various supported configurations. +This chapter describes the input and output files needed for executing the model in the various supported configurations. ============= Input files @@ -44,7 +44,7 @@ The static input files are listed and described in :numref:`Table %s ` * - global_mxsnoalb.uariz.t126.384.190.rg.grb - Climatological maximum snow albedo * - global_o3prdlos.f77 - - Monthly mean ozone coefficients + - Monthly mean ozone coefficients * - global_shdmax.0.144x0.144.grb - Climatological maximum vegetation cover * - global_shdmin.0.144x0.144.grb @@ -92,7 +92,7 @@ The input files containing grid information and the initial conditions are liste - Date-dependent * - C96_grid.tile[1-6].nc - C96 grid information for tiles 1-6 - - + - * - gfs_ctrl.nc - NCEP NGGPS tracers, ak, and bk - ✔ @@ -101,7 +101,7 @@ The input files containing grid information and the initial conditions are liste - ✔ * - oro_data.tile[1-6].nc - Model terrain (topographic/orographic information) for grid tiles 1-6 - - + - * - sfc_ctrl.nc - Control parameters for surface input: forecast hour, date, number of soil levels - @@ -144,7 +144,7 @@ The File Description lines are used to specify the name of the file(s) to which contain one or more sets of six required and five optional fields (optional fields are denoted by square brackets ``[ ]``). The lines containing File Descriptions can be intermixed with the lines containing Field Descriptions as long as files are defined before fields that are to be written them. File entries have the following format: - + .. code-block:: console "file_name", output_freq, "output_freq_units", file_format, "time_axis_units", "time_axis_name" @@ -193,7 +193,7 @@ These file line entries are described in :numref:`Table %s `. NOTE: If the new_file_freq field is present, then this field must also be present. * - start_time - CHARACTER(len=25), OPTIONAL - - Time to start the file for the first time. The format of this string is the same as the global date. + - Time to start the file for the first time. The format of this string is the same as the global date. NOTE: The new_file_freq and the new_file_freq_units fields must be present to use this field. * - file_duration - INTEGER, OPTIONAL @@ -209,26 +209,26 @@ These file line entries are described in :numref:`Table %s `. The field section of the diag_table specifies the fields to be output at run time. Only fields registered with ``register_diag_field()``, which is an API in the FMS ``diag_manager`` routine, can be used in the *diag_table*. - -Registration of diagnostic fields is done using the following syntax + +Registration of diagnostic fields is done using the following syntax .. code-block:: console diag_id = register_diag_field(module_name, diag_name, axes, ...) - + in file ``FV3/atmos_cubed_sphere/tools/fv_diagnostics.F90``. As an example, the sea level pressure is registered as: - + .. code-block:: console id_slp = register_diag_field (trim(field), 'slp', axes(1:2), & Time, 'sea-level pressure', 'mb', missing_value=missing_value, range=slprange ) - + All data written out by ``diag_manager`` is controlled via the *diag_table*. A line in the field section of the *diag_table* file contains eight variables with the following format: - + .. code-block:: console "module_name", "field_name", "output_name", "file_name", "time_sampling", "reduction_method", "regional_section", packing - + These field section entries are described in :numref:`Table %s `. .. _FieldDescription: @@ -260,26 +260,26 @@ These field section entries are described in :numref:`Table %s `. If the profile type is “fixed” then the tracer field values are set equal to the surface value. If the profile type is “profile” then the top/bottom of model and surface values are read -and an exponential profile is calculated, with the profile being dependent on the number of levels in the component model. +and an exponential profile is calculated, with the profile being dependent on the number of levels in the component model. .. _TracerTable: @@ -396,11 +396,11 @@ and an exponential profile is calculated, with the profile being dependent on th - surface_value = X, top_value = Y (atmosphere) For the case of - + .. code-block:: console "profile_type","profile","surface_value = 1e-12, top_value = 1e-15" - + in a 15 layer model this would return values of surf_value = 1e-12 and multiplier = 0.6309573, i.e 1e-15 = 1e-12*(0.6309573^15). A ``method`` is a way to allow a component module to alter the parameters it needs for various tracers. In essence, @@ -412,13 +412,13 @@ See ``FMS/field_manager/field_manager.F90`` for more information. *input.nml* file ------------------------------------ -The atmosphere model reads many parameters from a Fortran namelist file, named *input.nml*. This file contains +The atmosphere model reads many parameters from a Fortran namelist file, named *input.nml*. This file contains several Fortran namelist records, some of which are always required, others of which are only used when selected physics options are chosen. The following link describes the various physics-related namelist records: -https://dtcenter.org/GMTB/UFS/sci_doc/CCPPsuite_nml_desp.html +https://dtcenter.org/GMTB/v4.0/sci_doc/CCPPsuite_nml_desp.html The following link describes the stochastic physics namelist records @@ -467,9 +467,9 @@ shows the following parameters that can be set in *model_configure* at run-time. - start day of model integration - integer - 12 - * - start_hour - - start hour of model integration - - integer + * - start_hour + - start hour of model integration + - integer - 00 * - start_minute - start minute of model integration @@ -477,7 +477,7 @@ shows the following parameters that can be set in *model_configure* at run-time. - 0 * - start_second - start second of model integration - - integer + - integer - 0 * - nhours_fcst - total forecast length @@ -500,10 +500,10 @@ shows the following parameters that can be set in *model_configure* at run-time. - integer - 4 * - restart_interval - - frequency to output restart file + - frequency to output restart file - integer - 0 (write restart file at the end of integration) - * - quilting + * - quilting - flag to turn on quilt - logical - .true. @@ -519,16 +519,16 @@ shows the following parameters that can be set in *model_configure* at run-time. - flag to output history files - logical - .true. - * - num_files - - number of output files + * - num_files + - number of output files - integer - 2 * - filename_base - - file name base for the output files - - character(255) + - file name base for the output files + - character(255) - 'atm' 'sfc' - * - output_grid - - output grid + * - output_grid + - output grid - character(255) - gaussian_grid * - output_file @@ -536,7 +536,7 @@ shows the following parameters that can be set in *model_configure* at run-time. - character(255) - nemsio * - imo - - i-dimension for output grid + - i-dimension for output grid - integer - 384 * - jmo @@ -544,7 +544,7 @@ shows the following parameters that can be set in *model_configure* at run-time. - integer - 190 * - nfhout - - history file output frequency + - history file output frequency - integer - 3 * - nfhmax_hf @@ -578,11 +578,11 @@ are not usually changed. - integer - 1 * - RUN_CONTINUE - - Flag for more than one NEMS run - - logical + - Flag for more than one NEMS run + - logical - .false. * - ENS_SPS - - flag for the ensemble stochastic coupling flag + - flag for the ensemble stochastic coupling flag - logical - .false. * - calendar @@ -598,11 +598,11 @@ are not usually changed. - logical - .false. * - write_dopost - - flag to do post on write grid component + - flag to do post on write grid component - logical - .false. * - ideflate - - lossless compression level + - lossless compression level - integer - 1 (0:no compression, range 1-9) * - nbits @@ -618,7 +618,7 @@ are not usually changed. - logical - .true. * - iau_offset - - IAU offset lengdth + - IAU offset lengdth - integer - 0 @@ -663,14 +663,14 @@ Additional Information about the FMS Diagnostic Manager The UFS Weather Model output is managed through the FMS (Flexible Modeling System) diagnostic manager (``FMS/diag_manager``) and is configured using the *diag_table* file. Data can be written at any number of sampling and/or averaging intervals -specified at run-time. More information about the FMS diagnostic manager can be found at: +specified at run-time. More information about the FMS diagnostic manager can be found at: https://data1.gfdl.noaa.gov/summer-school/Lectures/July16/03_Seth1_DiagManager.pdf ------------------------------ Diagnostic Manager namelist ------------------------------ The ``diag_manager_nml`` namelist contains values to control the behavior of the diagnostic manager. Some -of the more common namelist options are described in :numref:`Table %s `. See +of the more common namelist options are described in :numref:`Table %s `. See ``FMS/diag_manager/diag_manager.F90`` for the complete list. .. _DiagManager: @@ -727,4 +727,3 @@ This release of the UFS Weather Model uses the following namelist: &diag_manager_nml prepend_date = .false. / - diff --git a/doc/UsersGuide/source/Introduction.rst b/doc/UsersGuide/source/Introduction.rst index d968ec6b1a..2cdd026ab0 100644 --- a/doc/UsersGuide/source/Introduction.rst +++ b/doc/UsersGuide/source/Introduction.rst @@ -53,8 +53,9 @@ For the UFS WM v1.0 release, the following aspects are supported: - Ability to run with or without SKEBS, SPPT, and SHUM. -- Ability to initialize from GFS files in Gridded Binary v2 (GRIB2) format for past dates, - starting January 1, 2018, when the preprocessing utility chgres is employed. Dates before +- Ability to initialize from GFS files in Gridded Binary v2 (GRIB2) or NEMS + Input/Output (NEMSIO) format for past dates, + starting January 1, 2018, when the preprocessing utility chgres_cube is employed. Dates before that may work, but are not guaranteed. - Output files in Network Common Data Form (NetCDF) format. @@ -69,10 +70,24 @@ In the GFS_v16beta suite, a moist TKE-based EDMF scheme replaces the K-based one The GFS_v15p2_no_nsst and the GFS_v16beta_no_nsst suites use a simple ocean scheme instead of the NSST scheme. This simple ocean scheme keeps the SST constant throughout the forecast and is recommended for use when the initial conditions do not contain all fields needed to initialize the NSST scheme. -It should be noted that the public release code reflects the state of development as of the fall of 2019, -and therefore the parameterizations contains innovations beyond what is currently in operations. -In other words, the GFDL microphysics distributed for use in GFS v15.2 and GFS v16beta -is the same scheme and contains development beyond what was transitioned to operations for GFS v15 in June 2019. + + +Even when using physics suite GFS_v15p2, the UFS WM v1 differs from the operational GFS v15.2 in a few ways. First, the public release code +reflects the state of development as of the fall of 2019, +and therefore the parameterizations contain innovations beyond what is in GFSv15.2 operations. +For example, the GFDL microphysics distributed for use in GFS v15.2 and GFS v16beta +is the same scheme and contains development beyond what was transitioned to operations +for GFS v15 in June 2019. Second, the public release code uses the CCPP as the +interface for calling physics, while in operations the Interoperable Physics Driver +(IPD) is used. NOAA is currently working toward phasing out the IPD from UFS applications. +Validation tests demonstrated that CCPP and IPD give bit-for-bit identical results +when the same physics is employed and selected performance flags are excluded at +compilation time. When performance compiler flags employed in operational production are used, runs with +CCPP and IPD for the same physics suite yield differences comparable to running +the model in different computational platforms. Finally, the operational GFS +runs in NOAA Central Operations computational platforms. When users run the model +in different platforms, the results will differ. + It should also be noted that further changes are expected to the GFS v16 suite before it is implemented in operations in 2021. The UFS WM v1 code is portable and can be used with Linux and Mac operating systems with Intel and GNU compilers. It has been tested in a variety of platforms widely used by atmospheric scientists, such as the NOAA research Hera system, the National Center for Atmospheric Research (NCAR) Cheyenne system, the National Science Foundation Stampede system, and Mac laptops. @@ -81,9 +96,9 @@ The UFS WM v1 code is portable and can be used with Linux and Mac operating syst At this time, the following aspects are unsupported: standalone regional domains, configurations in which a mediator is used to couple the atmospheric model to models of other earth domains (such as ocean, ice, and waves), horizontal resolutions other than the supported ones, different number or placement of vertical levels, physics suites other than GFS v15.2 and GFS v16beta the *cellular automata* stochastic scheme, initialization from sources other than GFS, the use of different file formats for input and output, and the use of the model in different computational platforms. It is expected that the UFS WM supported capabilities will be expanded in future releases. -It should be noted that the UFS WM is a component of the UFS Medium-Range Weather Application, which also contains pre- and post-processing components, a comprehensive build system, and workflows for configuration and execution of the application. At this time, the UFS WM is only supported to the general community for use as part of the UFS Medium-Range Weather Application. However, those wishing to contribute development to the UFS WM should become familiar with the procedures for running the model as a standalone component and for executing the regression tests described in this guide to make sure no inadvertent changes to the results have been introduced during the development process. +It should be noted that the UFS WM is a component of the UFS Medium-Range (MR) Weather Application (App), which also contains pre- and post-processing components, a comprehensive build system, and workflows for configuration and execution of the application. At this time, the UFS WM is only supported to the general community for use as part of the UFS MR Weather App. However, those wishing to contribute development to the UFS WM should become familiar with the procedures for running the model as a standalone component and for executing the regression tests described in this guide to make sure no inadvertent changes to the results have been introduced during the development process. -Support for the UFS WM is provided through the UFS Forum by the Developmental Testbed Center (DTC) and other groups involved in UFS development, such as NOAA’s Environmental Modeling Center (EMC), NOAA research laboratories (GFDL, NSSL, ESRL, and AOML), and NCAR. UFS users and developers are encouraged not only to post questions, but also to help address questions posted by other members of the community. +Support for the UFS WM is provided through the `UFS Forum `_ by the Developmental Testbed Center (DTC) and other groups involved in UFS development, such as NOAA’s Environmental Modeling Center (EMC), NOAA research laboratories (GFDL, NSSL, ESRL, and AOML), and NCAR. UFS users and developers are encouraged not only to post questions, but also to help address questions posted by other members of the community. This WM User’s Guide is organized as follows: @@ -99,8 +114,6 @@ This WM User’s Guide is organized as follows: contains a description of the :term:`Suite Definition File (SDF)` and namelists needed to configure the model for running with the GFS v15.2 and GFS v16beta physics suites. -The next chapter: - - :numref:`Chapter %s ` (Contributing development) goes beyond the capabilities supported in the public release to cover code management for conducting development and proposing contributions back to the authoritative code repositories. It should be noted that the regression tests described here are mandatory for committing code back to the ufs-weather-model authoritative code repository. These regressions tests differ from those distributed with the workflows for UFS applications, which are intended for application users and developers to assess the quality of their installations and the impact of their code changes. Finally, :numref:`Chapters %s ` and :numref:`%s ` contain a list of acronyms and a glossary, respectively. diff --git a/doc/UsersGuide/source/RegTests.rst b/doc/UsersGuide/source/RegTests.rst deleted file mode 100644 index 889c34a83a..0000000000 --- a/doc/UsersGuide/source/RegTests.rst +++ /dev/null @@ -1,245 +0,0 @@ -.. _RegTests: - -****************************************** -Regression Tests for Development -****************************************** - -* Motivation - -* Description of the default tests - -* Directory structure for inputs and outputs - -* How to run a subset of tests - -* Baselines: existing baselines, creating new baselines, comparing against a new baseline - -* Running regression tests - -* Checking the results - -* Adding a regression test - - -System Requirements, Libraries, and Compilers ---------------------------------------------- -The build system for the UFS with CCPP relies on the use of the Python scripting language, along with ``cmake``. - -The basic requirements for building and running the UFS with CCPP are listed below. The versions listed reflect successful tests and there is no guarantee that the code will work with different versions. - - * FORTRAN 90+ compiler versions - * ifort 15.1.133, 18.0.1.163 and 19.0.2 - * gfortran 6.2, 8.1, and 9.1 - * C compiler versions - * icc v18.0.1.163 and 19.0.2 - * gcc 6.2.0 and 8.1 - * AppleClang 10.0 - * MPI job scheduler versions - * mpt 2.19 - * impi 5.1.1.109 and 5.1.2.150 - * mpich 3.2.1 - * cmake versions 2.8.12.1, 2.8.12.2, and 3.6.2 - * netCDF with HDF5, ZLIB and SZIP versions 4.3.0, 4.4.0, 4.4.1.1, 4.5.0, 4.6.1, and 4.6.3 (not 3.x) - * Python versions 2.7.5, 2.7.9, and 2.7.13 (not 3.x) - -A number of NCEP libraries are required to build and run FV3 and are listed in :numref:`Table %s `. - -.. _NCEP_lib_FV3: - -.. table:: *NCEP libraries required to build the UFS Atmosphere* - - +---------------------------+-------------+----------------------------------------------------+ - | Library | Version | Description | - +===========================+=============+====================================================+ - | bacio | 2.0.1 | NCEP binary I/O library | - +---------------------------+-------------+----------------------------------------------------+ - | ip | 2.0.0/3.0.0 | NCEP general interpolation library | - +---------------------------+-------------+----------------------------------------------------+ - | nemsio | 2.2.3 | NEMS I/O routines | - +---------------------------+-------------+----------------------------------------------------+ - | sp | 2.0.2 | NCEP spectral grid transforms | - +---------------------------+-------------+----------------------------------------------------+ - | w3emc | 2.2.0 | NCEP/EMC library for decoding data in GRIB1 format | - +---------------------------+-------------+----------------------------------------------------+ - | w3nco/v2.0.6 | 2.0.6 | NCEP/NCO library for decoding data in GRIB1 format | - +---------------------------+-------------+----------------------------------------------------+ - -These libraries are prebuilt on most NOAA machines using the Intel compiler. For those needing to build the libraries themselves, GMTB recommends using the source code from GitHub at https://github.com/NCAR/NCEPlibs.git, which includes build files for various compilers and machines using OpenMP flags and which are thread-safe. - -In addition to the NCEP libraries, some additional external libraries are needed (:numref:`Table %s `). - -.. _ext_lib_FV3: - -.. table:: *External libraries necessary to build the UFS Atmosphere* - - +--------------------+-------------------------+---------------------------------------------------------------------------------------------+ - | Library | Version | Description | - +====================+=========================+=============================================================================================+ - | ESMF | V7.1.0r and v8.0.0_bs21 | Earth System Modeling Framework for coupling applications | - +--------------------+-------------------------+---------------------------------------------------------------------------------------------+ - | netCDF | 4.3.0 and 4.6.1 | Interface to data access functions for storing and retrieving data arrays | - +--------------------+-------------------------+---------------------------------------------------------------------------------------------+ - | SIONlib (optional) | v1.7.2 | Parallel I/O library (link) that can be used to read precomputed lookup tables instead of \ | - | | | computing them on the fly (or using traditional Fortran binary data files) | - +--------------------+-------------------------+---------------------------------------------------------------------------------------------+ - -The Earth System Modeling Framework (ESMF), the SIONlib, the NCEPlibs, and the netCDF libraries must be built with the same compiler as the other components of the UFS Atmosphere. - -Building the UFS Atmosphere ---------------------------- - -A complete listing and description of the FV3 build options were discussed elsewhere. This section will describe the commands needed to build the different options using the script ``compile.sh`` provided in the NEMSfv3gfs distribution. This script calls ``ccpp_prebuild.py``, so users do not need to run the *prebuild* step manually. All builds using ``compile.sh`` are made from the ``./tests`` directory of NEMSfv3gfs and follow the basic command: - -.. code-block:: console - - ./compile.sh $PWD/../FV3 system.compiler 'MAKEOPTS' - -Here, ``system`` stands for the machine on which the code is compiled and can be any of the following machines and compilers: *theia, jet, cheyenne, gaea, stampede, wcoss_cray, wcoss_dell_p3, supermuc_phase2, macosx*, or *linux*. - -``compiler`` stands for the compiler to use and depends on the system. For *theia* and *cheyenne*, the available options are ``intel`` and ``gnu``. For *macosx* and *linux*, the only tested compiler is ``gnu``. For all other platforms, ``intel`` is the only option at this time. - -The ``MAKEOPTS`` string, enclosed in single or double quotes, allows to specify options for compiling the code. The following options are of interest for building the CCPP version of NEMSfv3gfs: - -* **CCPP=Y** - enables :term:`CCPP` (default is ``N``) -* **STATIC=Y** - enables the CCPP static mode; requires ``CCPP=Y`` (default is ``N``) and ``SUITES=...`` (see below) -* **SUITES=XYZ, ABC, DEF, ...** - specify SDF(s) to use when compiling the code in CCPP static mode; SDFs are located in ``ccpp/suites/``, omit the path in the argument; requires ``CCPP=Y STATIC=Y`` (default is ``‘’``) -* **SION=Y** - enables support for the SIONlib I/O library (used by CCPP to read precomputed lookup tables instead of computing them on the fly); available on *Theia, Cheyenne, Jet*; also available on *Mac OS X* and *Linux* if instructions in ``doc/README_{macosx,linux}.txt`` are followed (default is ``N``) -* **32BIT=Y** - compiles FV3 dynamical core in single precision; note that physics are always compiled in double precision; this option is only available on *Theia, Cheyenne*, and *Jet* (default is ``N``) -* **REPRO=Y** - compiles code in :term:`REPRO` mode, i.e. removes certain compiler optimization flags used in the default :term:`PROD` mode to obtain bit-for-bit (b4b) identical results between CCPP and non-CCPP code (default is ``N``) -* **DEBUG=Y** - compiles code in DEBUG mode, i.e. removes all optimization of :term:`PROD` mode and add bound checks; mutually exclusive with ``REPRO=Y`` (default is ``N``) -* **TRANSITION=Y** - applies selective lowering of optimization for selected files to obtain b4b with non-CCPP code in PROD mode (only when using Intel 15 on *Theia*) - -Examples: - -* Compile non-CCPP code with 32-bit dynamics on *Theia* with the Intel compiler - - .. code-block:: console - - ./compile.sh $PWD/../FV3 theia.intel ‘32BIT=Y’ - -* Compile dynamic CCPP code in ``DEBUG`` mode on *Jet* - - .. code-block:: console - - ./compile.sh $PWD/../FV3 jet.intel ‘CCPP=Y DEBUG=Y’ - -* Compile static CCPP code for the CPT suite on *Linux* with the GNU compiler, enable support for the SIONlib I/O library (requires that the library to be installed) - - .. code-block:: console - - ./compile.sh $PWD/../FV3 linux.gnu ‘SION=Y CCPP=Y STATIC=Y SUITES=FV3_CPT_v0’ - -* *Cheyenne* static build with multiple suites: - - .. code-block:: console - - ./compile.sh $PWD/../FV3 cheyenne.intel ‘CCPP=Y STATIC=Y SUITES=FV3_GFS_v15,FV3_CPT_v0’ - - -Running the UFS Atmosphere Using the Regression Tests (RTs) ------------------------------------------------------------- - -Regression testing is the process of testing changes to the programs to make sure that the existing functionalities still work when changes are introduced. By running the RTs (or a subset of them by copying a RT configuration file and editing it), the code is compiled, the run directories are set up, and the code is executed. The results are typically compared against a pre-existing baseline, but in certain occasions it is necessary to first create a new baseline (for example, in a new platform where a baseline does not exist or when it is expected that a new development will change the answer). Because the RTs set up the run directories, this is a useful and easy way to get started, since all the model configuration files and necessary input data (initial conditions, fixed data) are copied into the right place. - -Overview of the RTs -^^^^^^^^^^^^^^^^^^^ - -The RT configuration files are located in ``./tests`` relative to the top-level directory of NEMSfv3gfs and have names ``rt*.conf``. The default RT configuration file, supplied with the NEMSfv3gfs master is called ``rt.conf`` and runs four types of configurations: IPD PROD, IPD REPRO, CCPP PROD, and CCPP REPRO. For the IPD configurations, CCPP is not used, that is, the code is compiled with ``CCPP=N``. The PROD configurations use the compiler flags used in NCEP operations for superior performance, while the REPRO configurations remove certain compiler flags to create b4b identical results between CCPP and IPD configurations. Before running the RT script ``rt.sh`` in directory ``./tests``, the user has to set some environment variables on the working shell: ``ACCNR`` (account to be charged for running the RTs), ``NEMS_COMPILER`` (optional for the ``intel`` compiler option, set to ``gnu`` to switch), and potentially ``RUNDIR_ROOT`` (location for the RT run directories), underneath which directories called ``rt_$PID`` are created (``$PID`` is the process identifier of the ``rt.sh`` invocation). This may be required on systems where the user does not have write permissions in the default run directory tree. - -.. code-block:: console - - export ACCNR=... - export NEMS_COMPILER=intel - export RUNDIR_ROOT=/full/path/under/which/rt_$PID/will/be/created - -Running the full default RT suite defined in ``rt.conf`` using the script ``rt.sh``: - -.. code-block:: console - - ./rt.sh -f - -This command can only be used on a NOAA machine using the Intel compiler, where an *official baseline* is available. For information on testing the CCPP code, or using alternate computational platforms, see the following sections. - -This command and all others below produce log output in ``./tests/log_machine.compiler``. These log files contain information on the location of the run directories that can be used as templates for the user. Each ``rt*.conf`` contains one or more compile commands preceding a number of tests. - - -Baselines -^^^^^^^^^^^^^^^^^^^ - -Regression testing is only possible on machines for which baselines exist. EMC maintains *official baselines* on *Theia* and *Wcoss* created with the Intel compiler. GMTB maintains additional baselines on *Jet*, *Cheyenne*, and *Gaea*. While GMTB is trying to keep up with changes to the official repositories, baselines maintained by GMTB are not guaranteed to be up-to-date. - -When porting the code to a new machine, it is useful to start by establishing a *personal baseline*. Future runs of the RT can then be compared against the *personal baseline* to ascertain that the results have not been inadvertently affected by code developments. The ``rt.sh -c`` option is used to create a *personal baseline*. - -.. code-block:: console - - ./rt.sh -l rt.conf -c fv3 # create own reg. test baseline - -Once the *personal baseline* has been created, future runs of the RT should be compared against the *personal baseline* using the ``-m`` option. - -.. code-block:: console - - ./rt.sh -l rt.conf -m # compare against own baseline - -The script rt.sh -^^^^^^^^^^^^^^^^^^^ - -``rt.sh`` is a bash shell file to run the RT and has the following options: - -.. code-block:: console - - Usage: $0 -c | -f | -s | -l | -m | -r | -e | -h - -c create new baseline results for - -f run full suite of regression tests - -s run standard suite of regression tests - -l run test specified in - -m compare against new baseline results - -r use Rocoto workflow manager - -e use ecFlow workflow manager - -h display this help - -The location of the run directories and *personal baseline* directories is controlled in ``rt.sh`` on a per-machine basis. The user is strongly advised to NOT modify the path to the *official baseline* directories. - -The *official baseline* directory is defined as: - -.. code-block:: console - - RTPWD=$DISKNM/trunk-yyyymmdd/${COMPILER} # on Cheyenne - RTPWD=$DISKNM/trunk-yyyymmdd # elsewhere - -Note that ``yyyymmdd`` is the year, month and day the baseline was created using top of master code. - -.. warning:: Modifying ``$DISKNM`` will break the RTs! - -*Personal baseline* results (see below) are stored in - -.. code-block:: console - - NEW_BASELINE=${STMP}/${USER}/FV3_RT/REGRESSION_TEST - -and RTs are run in ``$RUNDIR_ROOT``. - -Example: *Theia* - -.. code-block:: console - - ... - dprefix=/scratch4/NCEPDEV - DISKNM=$dprefix/nems/noscrub/emc.nemspara/RT - STMP=$dprefix/stmp4 - PTMP=$dprefix/stmp3 - .. - -In case a user does not have write permissions to ``$STMP (/scratch4/NCEPDEV/stmp4/)``, ``$STMP`` must be modified without modifying ``$DISKNM`` (i.e. ``dprefix``). Similarly, if the user does not have write permissions to ``$PTMP``, the user can set the ``$RUNDIR_ROOT`` environment variable to change the location of the run directories as described below. - -.. code-block:: console - - # Overwrite default RUNDIR_ROOT if environment variable RUNDIR_ROOT is set - RUNDIR_ROOT=${RUNDIR_ROOT:-${PTMP}/${USER}/FV3_RT}/rt_$$ - - -Compatibility between the Code Base, the SDF, and the Namelist in the UFS Atmosphere -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The variable ``suite_name`` within the ``namelist.input`` file used in the UFS Atmosphere determines which suite will be employed at run time (e.g., ``suite_name=FV3_GFS_v15``). It is the user’s responsibility to ascertain that the other variables in ``namelist.input`` are compatible with the chosen suite. When runs are executed using the RT framework described in the preceding sections, compatibility is assured. For new experiments, users are responsible for modifying the two files (``SDF`` and ``namelist.input``) consistently, since limited checks are in place. - -Information about the UFS Atmosphere physics namelist can be found with the CCPP Scientific Documentation at https://dtcenter.org/GMTB/v4.0/sci_doc/. diff --git a/doc/UsersGuide/source/SDFandNamelistExamplePractices.rst b/doc/UsersGuide/source/SDFandNamelistExamplePractices.rst index 67096cd0d0..8f54bb0b20 100644 --- a/doc/UsersGuide/source/SDFandNamelistExamplePractices.rst +++ b/doc/UsersGuide/source/SDFandNamelistExamplePractices.rst @@ -1,35 +1,44 @@ .. _SDFandNamelistExamplePractices: - + ******************************************** SDF and Namelist Samples and Best Practices ******************************************** -The public release of the medium-range weather app includes two supported physics suites: -GFSv15p2 and GFSv16beta. You will find the Suite Definition Files (SDFs) for these suites -in +The public release of the UFS MR Weather App includes four supported physics suites: +GFS_v15p2, GFS_v15p2_no_nsst, GFS_v16beta, and GFS_v16beta_no_nsst. You will +find the Suite Definition Files (SDFs) for these suites in -https://github.com/NOAA-EMC/fv3atm/tree/release/public-v1/ccpp/suites +https://github.com/NOAA-EMC/fv3atm/tree/ufs-v1.0.0/ccpp/suites (no other SDFs are available with this release). You will find the namelists for the C96 configuration here: -https://github.com/ufs-community/ufs-weather-model/tree/release/public-v1/parm/ccpp_v15p2_c96.nml.IN +https://github.com/ufs-community/ufs-weather-model/tree/ufs-v1.0.0/parm/ccpp_v15p2_c96.nml.IN and -https://github.com/ufs-community/ufs-weather-model/tree/release/public-v1/parm/ccpp_v16beta_c96.nml.IN +https://github.com/ufs-community/ufs-weather-model/tree/ufs-v1.0.0/parm/ccpp_v16beta_c96.nml.IN + +As noted in the file names, these namelists are for the operational (v15p2) and developmental (v16beta) +GFS suites. Each of these namelists are relevant to the suites with and without the SST prediction scheme, that is, +they are relevant for the suite that employs NSST and for the suite that employs the simple ocean +model (`no_nsst`). The only difference in the namelist regarding how SST prediction is +addressed is variable `nstf_name`. For more information about this variable and for information about +namelist options for higher resolution configurations, please consult the +`CCPP v4 Scientific Documentation `_. -The two CCPP suites for the medium-range weather app release are supported in four grid resolutions: +The four CCPP suites for the UFS MR Weather App release are supported in four grid resolutions: C96, C192, C384, and C768, with 64 vertical levels. -An in depth description of the namelist settings, SDFs, and parameterizations used in the GFSv15p2 -and GFSv16beta suites can be found in the CCPP Scientific Documentation (TODO add link). Note both suites do not +An in depth description of the namelist settings, SDFs, and parameterizations used +in all supported suites can be found in the `CCPP v4 Scientific Documentation `_. +Note both suites do not use stochastic physics by default, but the stochastic physics can be activated following the -instructions described here (TODO add link). +instructions described in the `stochastic physics v1 user's guide `_. -Both the SDF and the *input.nml* contain information about how to specify the physics suite. +Both the SDF and the *input.nml* contain information about how to specify the physics suite. Some of this information is redundant, and the user must make sure they are compatible. The safest practice is to use the SDF and namelist provided for each suite, since those are -supported configurations. +supported configurations. Changes to the SDF must be accompanied by corresponding changes to the namelist. While there is not a one-to-one correspondence between the namelist and the SDF, :numref:`Table %s ` @@ -51,92 +60,92 @@ shows some variables in the namelist that must match the SDF. - **PBL-related variables** - - - - + - - * - do_myjpbl - Flag to activate the MYJ PBL scheme - T - F - mypbl_wrapper - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - do_myjsfc - Flag to activate the MYJ PBL surface layer scheme - T, F - F - myjsfc_wrapper - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - do_mynnedmf - Flag to activate the MYNN-EDMF scheme - T, F - F - mynnedmf_wrapper - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - do_ysu - Flag to activate the YSU PBL scheme - T, F - F - ysudif - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - hybedmf - Flag to activate the K-based PBL scheme - T, F - F - hedmf - - Set to T for GFSv15p2 and F for GFSv16beta + - Set to T for GFSv15p2* and GFSv16beta* * - isatedmf - Flag for version of scale-aware TKE-based EDMF scheme - 0, 1 - 0 - 0=satmedmfvdif, 1=satmedmfvdifq - - Set to 0 for GFSv15p2 and 1 for GFSv16beta + - Set to 0 for GFSv15p2* and 1 for GFSv16beta* * - ism - Flag to choose a land surface model to use - 0, 1, 2 - 1 - 1=lsm_noah, 2=lsm_ruc - - Set to 1 for GFSv15p2 and GFSv16beta + - Set to 1 for GFSv15p2* and GFSv16beta* * - satedmf - Flag to activate the scale-aware TKE-based EDMF scheme - T, F - F - satmedmfvdif or satmedmfvdifq - - Set to T for GFSv15p2 and GFSv16beta + - Set to T for GFSv15p2* and GFSv16beta* * - shinhong - Flag to activate the Shin-Hong PBL parameterization - T, F - F - shinhongdif - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - - **Convection-releated flags** - - - - + - - * - cscnv - Flag to activate the Chikira-Sugiyama deep convection scheme - T, F - F - cs_conv - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - do_aw - Flag to activate the Arakawa-Wu extension to the Chikira-Sugiyama deep convection scheme - T, F - F - cs_conv_aw_adj - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - imfdeepcnv - Flag to choose a mass flux deep convective scheme - -1, 2, 3, 4 - -1 - -1=no deep convection*, 2=samfshalcnv, 3=cu_gf_driver, 4=cu_ntiedtke - - Set to 2 for GFSv15p2 and GFSv16beta + - Set to 2 for GFSv15p2* and GFSv16beta* * - imfshalcvn - Flag to choose a mass flux shallow convective scheme - -1, 2, 3, 4 - -1 - -1=no deep convection*, 2=samfshalcnv, 3=cu_gf_driver, 4=cu_ntiedtke - - Set to 2 for GFSv15p2 and GFSv16beta + - Set to 2 for GFSv15p2* and GFSv16beta* \*Even when imfdeepcvn=-1, the Chikira-Sugiyama deep convection scheme may be specified using cscnv=T. @@ -154,63 +163,63 @@ the namelist are listed in :numref:`Table %s `. - Possible Values - Default - Used with CCPP scheme - - Recommentation + - Recommendation * - - **Miscellaneous variables** - - - - + - - * - do_myjsfc - Flag to activate the MYJ PBL surface scheme - T, F - F - mynnsfc_wrapper - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - do_shoc - - Flag to activate the Simplified Higher-Order Closure (SHOC) parameterization + - Flag to activate the Simplified Higher-Order Closure (SHOC) parameterization - T, F - F - shoc - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - do_ugwp** - Flag to activate the unified Gravity Wave Physics parameterization - T, F - F - cires_ugwp - - Set to F for GFSv15p2 and GFSv16beta + - Set to F for GFSv15p2* and GFSv16beta* * - imp_physics - Flag to choose a microphysics scheme - 8, 10, 11 - 99 - - 8=mp_thompson, 10=m_micro, 11=gfdl_could_microphys - - Set to 11 for GFSv15p2 and GFSv16beta + - 8=mp_thompson, 10=m_micro, 11=gfdl_cloud_microphysics + - Set to 11 for GFSv15p2* and GFSv16beta* * - lsm - Flag to choose a land surface model to use - 0, 1, 2 - 1 - 1=lsm_noah, 2=lsm_ruc - - Set to 1 for GFSv15p2 and GFSv16beta + - Set to 1 for GFSv15p2* and GFSv16beta* * - lsoil - Number of soil layers - 4, 9 - 4 - 4 for lsm_noah, 9 for lsm_ruc - - Set to 4 for GFSv15p2 and GFSv16beta + - Set to 4 for GFSv15p2* and GFSv16beta* * - h2o_phys - Flag for stratosphere h2o scheme - T, F - - + - - h2ophys - - Set to T for GFSv15p2 and GFSv16beta + - Set to T for GFSv15p2* and GFSv16beta* * - oz_phys_2015 - Flag for new (2015) ozone physics - T, F - - + - - ozphys_2015 - - Set to T for GFSv15p2 and GFSv16beta + - Set to T for GFSv15p2* and GFSv16beta* -\*\*The CIRES Unified Gravity Wave Physics (cires_ugwp) scheme is used in GFSv15p2 and GFSv16beta SDFs with do_ugwp=F in the namelist. In this setting, the cires_ugwp calls the operational GFS v15.2 orographic gravity wave drag (gwdps) scheme. When do_ugwp=T, the cires_ugwp scheme calls an experimental orographic gravity wave (gwdps_v0). +\*\*The CIRES Unified Gravity Wave Physics (cires_ugwp) scheme is used in GFSv15p2* and GFSv16beta* SDFs with do_ugwp=F in the namelist. In this setting, the cires_ugwp calls the operational GFS v15.2 orographic gravity wave drag (gwdps) scheme. When do_ugwp=T, the cires_ugwp scheme calls an experimental orographic gravity wave (gwdps_v0). **Note that some namelist variables are not available for use with CCPP.** @@ -231,9 +240,9 @@ Some examples are shown in** :numref:`Table %s `. * - Namelist setting - Enabled namelist variables * - do_ugwp=T - - All variables in namelist record &cires_ugwp_nml plus do_tofd. Additionally, if namelist variable cnvgwd=T and + - All variables in namelist record &cires_ugwp_nml plus do_tofd. Additionally, if namelist variable cnvgwd=T and the third and fourth position of namelist array cdmbgwd are both 1, then the convective gravity wave drag that - is part of cires_ugwp will be called. (Not supported with the UFS) + is part of cires_ugwp will be called. (Not supported with the UFS) * - do_mynnedmf=T - bl_mynn_tkeadvect, bl_mynn_edmf, bl_mynn_edmf_mom (Not supported with the UFS) * - imp_physics=99 @@ -244,4 +253,3 @@ Some examples are shown in** :numref:`Table %s `. - All variables in namelist record gfdl_cloud_microphysics_nml and lgfdlmprad * - satedmf=T - isatedmf -