diff --git a/docs/requirements.txt b/docs/requirements.txt index 7be32f52..36f1f18b 100644 --- a/docs/requirements.txt +++ b/docs/requirements.txt @@ -1,3 +1,4 @@ sphinxcontrib-bibtex sphinx_rtd_theme -docutils==0.16 \ No newline at end of file +docutils==0.16 +urllib3==1.26.15 \ No newline at end of file diff --git a/docs/source/BuildRunLandDA.rst b/docs/source/BuildRunLandDA.rst index cb7eb932..66e991a0 100644 --- a/docs/source/BuildRunLandDA.rst +++ b/docs/source/BuildRunLandDA.rst @@ -70,7 +70,7 @@ Clone the Land DA repository. .. code-block:: console - git clone -b release/public-v1.0.0 --recursive https://github.com/NOAA-EPIC/land-offline_workflow.git + git clone -b develop --recursive https://github.com/ufs-community/land-DA_workflow.git Build the Land DA System *************************** @@ -79,7 +79,7 @@ Build the Land DA System .. code-block:: console - cd $LANDDAROOT/land-offline_workflow + cd $LANDDAROOT/land-DA_workflow module use modulefiles module load landda_.intel @@ -103,7 +103,8 @@ Build the Land DA System .. code-block:: console - [100%] Built target ufsLandDriver.exe + [100%] Completed 'ufs-weather-model' + [100%] Built target ufs-weather-model Additionally, the ``build`` directory will contain several files and a ``bin`` subdirectory with three executables: @@ -114,7 +115,7 @@ Build the Land DA System Configure the Experiment *************************** -#. Navigate back to the ``land-offline_workflow`` directory and check that the account/partition is correct in ``submit_cycle.sh``. +#. Navigate back to the ``land-DA_workflow`` directory and check that the account/partition is correct in ``submit_cycle.sh``. .. code-block:: console @@ -130,7 +131,7 @@ Configure the Experiment where ``my_partition`` is the name of the partition on the user's system. -#. Configure other elements of the experiment if desired. The v1.0.0 release includes four scripts with default experiment settings: +#. Configure other elements of the experiment if desired. The ``develop`` branch includes four scripts with default experiment settings: * ``settings_DA_cycle_gdas`` for running the Jan. 1-3, 2016 sample case. * ``settings_DA_cycle_era5`` for running a Jan. 1-3, 2020 sample case. diff --git a/docs/source/Container.rst b/docs/source/Container.rst index 32a43150..7cb7e1ee 100644 --- a/docs/source/Container.rst +++ b/docs/source/Container.rst @@ -86,7 +86,7 @@ where ``/path/to/landda`` is the path to this top-level directory (e.g., ``/User NOAA RDHPCS Systems ---------------------- -On many NOAA :term:`RDHPCS` systems, a container named ``ubuntu20.04-intel-landda.img`` has already been built, and users may access the container at the locations in :numref:`Table %s `. +On many NOAA :term:`RDHPCS` systems, a container named ``ubuntu20.04-intel-ue-landda.img`` has already been built, and users may access the container at the locations in :numref:`Table %s `. .. _PreBuiltContainers: @@ -107,18 +107,22 @@ On many NOAA :term:`RDHPCS` systems, a container named ``ubuntu20.04-intel-landd .. note:: Singularity is not available on Gaea, and therefore, container use is not supported on Gaea. -Users can simply set an environment variable to point to the container, as described in :numref:`Section %s `. +Users can simply set an environment variable to point to the container: + +.. code-block:: console + + export img=path/to/ubuntu20.04-intel-ue-landda.img If users prefer, they may copy the container to their local working directory. For example, on Jet: .. code-block:: console - cp /mnt/lfs4/HFIP/hfv3gfs/role.epic/containers/ubuntu20.04-intel-landda.img . + cp /mnt/lfs4/HFIP/hfv3gfs/role.epic/containers/ubuntu20.04-intel-ue-landda.img . Other Systems ---------------- -On other systems, users can build the Singularity container from a public Docker :term:`container` image or download the container from the `Land DA Data Bucket `__. Downloading may be faster depending on the download speed on the user's system. +On other systems, users can build the Singularity container from a public Docker :term:`container` image or download the ``ubuntu20.04-intel-landda.img`` container from the `Land DA Data Bucket `__. Downloading may be faster depending on the download speed on the user's system. However, the container in the data bucket is the ``release/v1.0.0`` container rather than the updated ``develop`` branch container. To download from the data bucket, users can run: @@ -130,7 +134,7 @@ To build the container from a Docker image, users can run: .. code-block:: console - singularity build ubuntu20.04-intel-landda.img docker://noaaepic/ubuntu20.04-intel-landda:release-public-v1.0.0 + singularity build --force ubuntu20.04-intel-ue-landda.img docker://noaaepic/ubuntu20.04-intel-ue-landda:unified-dev-testmp This process may take several hours depending on the system. @@ -145,7 +149,7 @@ Get Data In order to run the Land DA System, users will need input data in the form of fix files, model forcing files, restart files, and observations for data assimilation. These files are already present on NOAA RDHPCS systems (see :numref:`Section %s ` for details). -Users on any system may download and untar the data from the `Land DA Data Bucket `__ into their ``$LANDDAROOT`` directory. +Users on any system may download and untar the data from the `Land DA Data Bucket `__ into their ``$LANDDAROOT`` directory. .. code-block:: console @@ -174,7 +178,7 @@ Save the location of the container in an environment variable. .. code-block:: console - export img=path/to/ubuntu20.04-intel-landda.img + export img=path/to/ubuntu20.04-intel-ue-landda.img Set the ``USE_SINGULARITY`` environment variable to "yes". @@ -188,28 +192,28 @@ Users may convert a container ``.img`` file to a writable sandbox. This step is .. code-block:: console - singularity build --sandbox ubuntu20.04-intel-landda $img + singularity build --sandbox ubuntu20.04-intel-ue-landda $img When making a writable sandbox on NOAA RDHPCS systems, the following warnings commonly appear and can be ignored: .. code-block:: console INFO: Starting build... - INFO: Verifying bootstrap image ubuntu20.04-intel-landda.img + INFO: Verifying bootstrap image ubuntu20.04-intel-ue-landda.img WARNING: integrity: signature not found for object group 1 WARNING: Bootstrap image could not be verified, but build will continue. -From within the ``$LANDDAROOT`` directory, copy the ``land-offline_workflow`` directory out of the container. +From within the ``$LANDDAROOT`` directory, copy the ``land-DA_workflow`` directory out of the container. .. code-block:: console - singularity exec -H $PWD $img cp -r /opt/land-offline_workflow . + singularity exec -H $PWD $img cp -r /opt/land-DA_workflow . -There should now be a ``land-offline_workflow`` directory in the ``$LANDDAROOT`` directory. Navigate into the ``land-offline_workflow`` directory. If for some reason, this is unsuccessful, users may try a version of the following command instead: +There should now be a ``land-DA_workflow`` directory in the ``$LANDDAROOT`` directory. Navigate into the ``land-DA_workflow`` directory. If for some reason, this is unsuccessful, users may try a version of the following command instead: .. code-block:: console - singularity exec -B /:/ $img cp -r /opt/land-offline_workflow . + singularity exec -B /:/ $img cp -r /opt/land-DA_workflow . where ```` and ```` are replaced with a top-level directory on the local system and in the container, respectively. Additional directories can be bound by adding another ``-B /:/`` argument before the container location (``$img``). @@ -221,11 +225,11 @@ where ```` and ```` are replaced with a top-level Sometimes binding directories with different names can cause problems. In general, it is recommended that the local base directory and the container directory have the same name. For example, if the host system's top-level directory is ``/user1234``, the user may want to convert the ``.img`` file to a writable sandbox and create a ``user1234`` directory in the sandbox to bind to. -Navigate to the ``land-offline_workflow`` directory after it has been successfully copied into ``$LANDDAROOT``. +Navigate to the ``land-DA_workflow`` directory after it has been successfully copied into ``$LANDDAROOT``. .. code-block:: console - cd land-offline_workflow + cd land-DA_workflow When using a Singularity container, Intel compilers and Intel :term:`MPI` (preferably 2020 versions or newer) need to be available on the host system to properly launch MPI jobs. Generally, this is accomplished by loading a module with a recent Intel compiler and then loading the corresponding Intel MPI. For example, users can modify the following commands to load their system's compiler/MPI combination: @@ -263,13 +267,19 @@ Run the Experiment The Land DA System uses a script-based workflow that is launched using the ``do_submit_cycle.sh`` script. That script requires an input file that details all the specifics of a given experiment. EPIC has provided four sample ``settings_*`` files as examples: ``settings_DA_cycle_gdas``, ``settings_DA_cycle_era5``, ``settings_DA_cycle_gdas_restart``, and ``settings_DA_cycle_era5_restart``. The ``*restart`` settings files will only work after an experiment with the corresponding non-restart settings file has been run. This is because they are designed to use the restart files created by the first experiment cycle to pick up where it left off. (e.g., ``settings_DA_cycle_gdas`` runs from 2016-01-01 at 18z to 2016-01-03 at 18z. The ``settings_DA_cycle_gdas_restart`` will run from 2016-01-03 at 18z to 2016-01-04 at 18z.) +First, update the ``$BASELINE`` environment variable in the selected ``settings_DA_*`` file to say ``singularity.internal`` instead of ``hera.internal``: + +.. code-block:: console + + export BASELINE=singularity.internal + To start the experiment, run: .. code-block:: console ./do_submit_cycle.sh settings_DA_cycle_gdas -The ``do_submit_cycle.sh`` script will read the ``settings_DA_cycle_*`` file and the ``release.environment`` file, which contain sensible experiment default values to simplify the process of running the workflow for the first time. Advanced users will wish to modify the parameters in ``do_submit_cycle.sh`` to fit their particular needs. After reading the defaults and other variables from the settings files, ``do_submit_cycle.sh`` creates a working directory (named ``workdir`` by default) and an output directory called ``landda_expts`` in the parent directory of ``land-offline_workflow`` and then submits a job (``submit_cycle.sh``) to the queue that will run through the workflow. If all succeeds, users will see ``log`` and ``err`` files created in ``land-offline_workflow`` along with a ``cycle.log`` file, which will show where the cycle has ended. The ``landda_expts`` directory will also be populated with data in the following directories: +The ``do_submit_cycle.sh`` script will read the ``settings_DA_cycle_*`` file and the ``release.environment`` file, which contain sensible experiment default values to simplify the process of running the workflow for the first time. Advanced users will wish to modify the parameters in ``do_submit_cycle.sh`` to fit their particular needs. After reading the defaults and other variables from the settings files, ``do_submit_cycle.sh`` creates a working directory (named ``workdir`` by default) and an output directory called ``landda_expts`` in the parent directory of ``land-DA_workflow`` and then submits a job (``submit_cycle.sh``) to the queue that will run through the workflow. If all succeeds, users will see ``log`` and ``err`` files created in ``land-DA_workflow`` along with a ``cycle.log`` file, which will show where the cycle has ended. The ``landda_expts`` directory will also be populated with data in the following directories: .. code-block:: console diff --git a/docs/source/DASystem.rst b/docs/source/DASystem.rst index 991166a3..068d7f5b 100644 --- a/docs/source/DASystem.rst +++ b/docs/source/DASystem.rst @@ -4,7 +4,7 @@ Land Data Assimilation System *************************************************** -This chapter describes the configuration of the offline Land :term:`Data Assimilation` (DA) System, which utilizes the UFS Noah-MP components with the JEDI ``fv3-bundle`` to enable cycled model forecasts. The data assimilation framework applies the Local Ensemble Transform Kalman Filter-Optimal Interpolation (LETKF-OI) algorithm to combine the state-dependent background error derived from an ensemble forecast with the observations and their corresponding uncertainties to produce an analysis ensemble (:cite:t:`HuntEtAl2007`, 2007). +This chapter describes the configuration of the offline Land :term:`Data Assimilation` (DA) System, which utilizes the UFS Noah-MP component together with JEDI's ``jedi-bundle`` (Skylab v3.0) to enable cycled model forecasts. The data assimilation framework applies the Local Ensemble Transform Kalman Filter-Optimal Interpolation (LETKF-OI) algorithm to combine the state-dependent background error derived from an ensemble forecast with the observations and their corresponding uncertainties to produce an analysis ensemble (:cite:t:`HuntEtAl2007`, 2007). Joint Effort for Data Assimilation Integration (JEDI) ******************************************************** @@ -622,7 +622,7 @@ GHCN files for 2016 and 2020 are already provided in IODA format for the v1.0.0 In each experiment, the ``DA_config`` file sets the name of the experiment configuration file. This configuration file is typically named ``settings_DA_test``. Before assimilation, if "GHCN" was specified as the observation type in the ``DA_config`` file, the ``ghcn_snwd_ioda_${YYYY}${MM}${DD}.nc`` file corresponding to the specified cycle date is soft-linked to the JEDI working directory (``${JEDIWORKDIR}``) with a naming-convention change (i.e., ``GHCN_${YYYY}${MM}${DD}${HH}.nc``). Here, the GHCN IODA file is appended with the cycle hour, ``${HH}`` which is extracted from the ``${STARTDATE}`` variable defined in the relevant ``DA_config`` file. -Prior to ingesting the GHCN IODA files via the LETKF at the DA analysis time, the observations are further quality controlled and checked using ``letkf_land.yaml`` (itself a concatenation of ``GHCN.yaml`` and ``letkfoi_snow.yaml``; see the `GitHub yaml files `__ for more detail). The GHCN-specific observation filters, domain checks, and quality control parameters from ``GHCN.yaml`` ensure that only snow depth observations which meet specific criteria are assimilated (the rest are rejected). The contents of this YAML are listed below: +Prior to ingesting the GHCN IODA files via the LETKF at the DA analysis time, the observations are further quality controlled and checked using ``letkf_land.yaml`` (itself a concatenation of ``GHCN.yaml`` and ``letkfoi_snow.yaml``; see the `GitHub yaml files `__ for more detail). The GHCN-specific observation filters, domain checks, and quality control parameters from ``GHCN.yaml`` ensure that only snow depth observations which meet specific criteria are assimilated (the rest are rejected). The contents of this YAML are listed below: .. code-block:: console @@ -910,7 +910,7 @@ The ``do_submit_cycle.sh`` script sets up the cycling job based on the user's in .. _DoSubmitCyclePng: -.. figure:: https://github.com/NOAA-EPIC/land-offline_workflow/wiki/do_submit_cycle.png +.. figure:: https://github.com/ufs-community/land-DA_workflow/wiki/do_submit_cycle.png :alt: The do submit cycle shell script starts by loading configuration files and modules. Then it proceeds to set executables, read in dates, compute forecast run variables, and setup work and output directories for the model. If a restart directory is available in the model output directory, it creates the dates file and submits the submit cycle shell script. If there is no output file, the script will try to copy restart files from an initial conditions directory before creating the dates file and submitting the submit cycle shell script. *Flowchart of 'do_submit_cycle.sh'* @@ -925,7 +925,7 @@ The ``submit_cycle.sh`` script first exports the required paths and loads the re .. _SubmitCyclePng: -.. figure:: https://github.com/NOAA-EPIC/land-offline_workflow/wiki/submit_cycle.png +.. figure:: https://github.com/ufs-community/land-DA_workflow/wiki/submit_cycle.png :alt: The submit cycle shell script starts by exporting paths and loading required modules. Then it starts a loop for the cycle. For each cycle in the experiment, it gets the data assimilation settings and date/time info; computes the restart frequency, run days, and run hours; and copies the restarts into the work directory. If the user is running a DA experiment, the script updates and submits the vector to tile namelists and submits the snow data assimilation. Then it submits the tile to vector namelists and saves the analysis restart. Regardless of whether DA is being used, the script runs the forecast model, updates the model namelist, and submits the land surface model. It checks existing model output, and then the loop ends. If there are more cycles to run, the script will run through this loop until they are complete. *Flowchart of 'submit_cycle.sh'* @@ -1037,7 +1037,7 @@ The ``do_landDA.sh`` runs the data assimilation job inside the ``sumbit_cycle.sh .. _DoLandDAPng: -.. figure:: https://github.com/NOAA-EPIC/land-offline_workflow/wiki/do_landDA.png +.. figure:: https://github.com/ufs-community/land-DA_workflow/wiki/do_landDA.png :alt: The do land da shell script starts by reading in the configuration file and setting up directories. Then it formats date strings, stages restart files, and prepares the observation files. It constructs yaml files based on requested JEDI type and then proceeds to create the background ensembles using LETKF-OI. Next, the script runs JEDI and applies the increment to use restarts. Lastly, it performs clean-up operations. *Flowchart of 'do_landDA.sh'* @@ -1102,4 +1102,3 @@ Below, users can find an example of a configuration settings file, ``settings_DA ``fv3bundle_vn`` Specifies the date for JEDI ``fv3-bundle`` checkout (used to select correct ``yaml``). - diff --git a/docs/source/Glossary.rst b/docs/source/Glossary.rst index 9f4eec91..d3886647 100644 --- a/docs/source/Glossary.rst +++ b/docs/source/Glossary.rst @@ -18,6 +18,14 @@ Glossary data assimilation One of the major sources of error in weather and climate forecasts is uncertainty related to the initial conditions that are used to generate future predictions. Even the most precise instruments have a small range of unavoidable measurement error, which means that tiny measurement errors (e.g., related to atmospheric conditions and instrument location) can compound over time. These small differences result in very similar forecasts in the short term (i.e., minutes, hours), but they cause widely divergent forecasts in the long term. Errors in weather and climate forecasts can also arise because models are imperfect representations of reality. Data assimilation systems seek to mitigate these problems by combining the most timely observational data with a "first guess" of the atmospheric state (usually a previous forecast) and other sources of data to provide a "best guess" analysis of the atmospheric state to start a weather or climate simulation. When combined with an "ensemble" of model runs (many forecasts with slightly different conditions), data assimilation helps predict a range of possible atmospheric states, giving an overall measure of uncertainty in a given forecast. + ESMF + `Earth System Modeling Framework `__. The ESMF defines itself as "a suite of software tools for developing high-performance, multi-component Earth science modeling applications." It is a community-developed software infrastructure for building and coupling models. + + FMS + The Flexible Modeling System (FMS) is a software framework for supporting the efficient + development, construction, execution, and scientific interpretation of atmospheric, + oceanic, and climate system models. + forcing data In coupled mode, data that are generated by one component of a model can be fed into another component to provide required input describing the state of the Earth system. When models are run in offline, or "uncoupled" mode, the model does not receive this input from another active component, so "forcing" files are provided. These files may consist of observational data or data gathered when running other components separately, and they contain values for the required input fields. @@ -38,6 +46,18 @@ Glossary netCDF NetCDF (`Network Common Data Form `__) is a file format and community standard for storing multidimensional scientific data. It includes a set of software libraries and machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. + NUOPC + National Unified Operational Prediction Capability + The `National Unified Operational Prediction Capability `__ is a consortium of Navy, NOAA, and Air Force modelers and their research partners. It aims to advance the weather modeling systems used by meteorologists, mission planners, and decision makers. NUOPC partners are working toward a common model architecture --- a standard way of building models --- in order to make it easier to collaboratively build modeling systems. + + NUOPC Layer + The :term:`NUOPC` Layer "defines conventions and a set of generic components for building coupled models using the Earth System Modeling Framework (:term:`ESMF`)." + NUOPC applications are built on four generic components: driver, model, mediator, and connector. For more information, visit the `NUOPC website `__. + + NUOPC Cap + NUOPC Model Cap + A NUOPC "cap" is an interface between a given model component and the rest of a coupled model system. It is a small software layer that sits on top of the component model, making calls into it. + NWP Numerical Weather Prediction (NWP) takes current observations of weather and processes them with computer models to forecast the future state of the weather. diff --git a/docs/source/Introduction.rst b/docs/source/Introduction.rst index db84d759..02f5e290 100644 --- a/docs/source/Introduction.rst +++ b/docs/source/Introduction.rst @@ -19,7 +19,7 @@ This User's Guide is organized as follows: * :numref:`Chapter %s ` (DA Framework) provides information on the DA system, required data, and configuration parameters. * :numref:`Chapter %s ` (Glossary) lists important terms. -Users and developers may post questions and exchange information on the Land DA System's `GitHub Discussions `__ forum if their concerns are not addressed in this User's Guide. +Users and developers may post questions and exchange information on the Land DA System's `GitHub Discussions `__ forum if their concerns are not addressed in this User's Guide. The Land DA System citation is as follows and should be used when presenting results based on research conducted with the Land DA System: @@ -48,7 +48,7 @@ government, industry, and academia). For more information about the UFS, visit t Noah-MP ========== -The offline Noah-MP LSM is a stand-alone, uncoupled model used to execute land surface simulations. In this traditional uncoupled mode, near-surface atmospheric forcing data is required as input forcing. This LSM simulates soil moisture (both liquid and frozen), soil temperature, skin temperature, snow depth, snow water equivalent (SWE), snow density, canopy water content, and the energy flux and water flux terms of the surface energy balance and surface water balance. +The offline Noah-MP LSM is a stand-alone, uncoupled model used to execute land surface simulations. In this traditional uncoupled mode, near-surface atmospheric :term:`forcing data` are required as input forcing. This LSM simulates soil moisture (both liquid and frozen), soil temperature, skin temperature, snow depth, snow water equivalent (SWE), snow density, canopy water content, and the energy flux and water flux terms of the surface energy balance and surface water balance. Noah-MP uses a big-leaf approach with a separated vegetation canopy accounting for vegetation effects on surface energy and water balances, a modified two-stream diff --git a/docs/source/Model.rst b/docs/source/Model.rst index dbe82be2..1ab65aa6 100644 --- a/docs/source/Model.rst +++ b/docs/source/Model.rst @@ -24,7 +24,7 @@ the static file (``ufs-land_C96_static_fields.nc``), the initial conditions file (``ufs-land_C96_init_*.nc``), and the model configuration file (``ufs-land.namelist.noahmp``). These files and their parameters are described in the following subsections. -They are publicly available via the `Land DA Data Bucket `__. +They are publicly available via the `Land DA Data Bucket `__. Users can download the data and untar the file via the command line, replacing ``{YEAR}`` with the year for the desired data. Release data is currently available for 2016 and 2020: diff --git a/docs/source/TechnicalOverview.rst b/docs/source/TechnicalOverview.rst index aa3ce23c..d974baff 100644 --- a/docs/source/TechnicalOverview.rst +++ b/docs/source/TechnicalOverview.rst @@ -28,7 +28,7 @@ The Land DA System requires: * :term:`NetCDF` * Lmod * `spack-stack `__ - * `FV3-bundle `__ + * `jedi-bundle `__ (Skylab v3.0.) These software prerequisites are pre-installed in the Land DA :term:`container` and on other Level 1 systems (see :ref:`below ` for details). However, users on non-Level 1 systems will need to install them. @@ -49,23 +49,23 @@ Four levels of support have been defined for :term:`UFS` applications, and the L Level 1 Systems ================== -Preconfigured (Level 1) systems for Land DA already have the required external libraries available in a central location via :term:`spack-stack` and :term:`JEDI`'s ``fv3-bundle``. Land DA is expected to build and run out-of-the-box on these systems, and users can download the Land DA code without first installing prerequisite software. With the exception of the Land DA container, users must have access to these Level 1 systems in order to use them. - -+-----------+-----------------------------------+----------------------------------------------------------------------------+ -| Platform | Compiler/MPI | spack-stack & fv3-bundle Installations | -+===========+===================================+============================================================================+ -| Hera | intel/2022.1.2 / | /scratch1/NCEPDEV/nems/role.epic/spack-stack/envs/landda-release-1.0-intel | -| | | | -| | impi/2022.1.2 | /scratch1/NCEPDEV/nems/role.epic/contrib/fv3-bundle | -+-----------+-----------------------------------+----------------------------------------------------------------------------+ -| Orion | intel/2022.1.2 / | /work/noaa/epic-ps/role-epic-ps/spack-stack/envs/landda-release-1.0-intel | -| | | | -| | impi/2022.1.2 | /work/noaa/epic-ps/role-epic-ps/contrib/fv3-bundle | -+-----------+-----------------------------------+----------------------------------------------------------------------------+ -| Container | intel-oneapi-compilers/2021.8.0 / | /opt/spack-stack/ (inside the container) | -| | | | -| | intel-oneapi-mpi/2021.8.0 | /opt/fv3-bundle (inside the container) | -+-----------+-----------------------------------+----------------------------------------------------------------------------+ +Preconfigured (Level 1) systems for Land DA already have the required external libraries available in a central location via the :term:`spack-stack` Unified Environment (UE) and the ``jedi-bundle`` (Skylab v3.0). Land DA is expected to build and run out-of-the-box on these systems, and users can download the Land DA code without first installing prerequisite software. With the exception of the Land DA container, users must have access to these Level 1 systems in order to use them. + ++-----------+-----------------------------------+-----------------------------------------------------------------------------------+ +| Platform | Compiler/MPI | spack-stack & jedi-bundle Installations | ++===========+===================================+===================================================================================+ +| Hera | intel/2022.1.2 / | /scratch1/NCEPDEV/nems/role.epic/spack-stack/spack-stack-1.3.0/envs/unified-env | +| | | | +| | impi/2022.1.2 | /scratch1/NCEPDEV/nems/role.epic/contrib/jedi-bundle | ++-----------+-----------------------------------+-----------------------------------------------------------------------------------+ +| Orion | intel/2022.1.2 / | /work/noaa/epic-ps/role-epic-ps/spack-stack/spack-stack-1.3.0/envs/unified-env | +| | | | +| | impi/2022.1.2 | /work/noaa/epic-ps/role-epic-ps/contrib/jedi-bundle | ++-----------+-----------------------------------+-----------------------------------------------------------------------------------+ +| Container | intel-oneapi-compilers/2021.8.0 / | /opt/spack-stack/ (inside the container) | +| | | | +| | intel-oneapi-mpi/2021.8.0 | /opt/jedi-bundle (inside the container) | ++-----------+-----------------------------------+-----------------------------------------------------------------------------------+ Level 2-4 Systems =================== @@ -82,12 +82,13 @@ Code Repositories and Directory Structure Directory Structure ====================== -The main repository for the Land DA System is named ``land-offline_workflow``; -it is available on GitHub at https://github.com/NOAA-EPIC/land-offline_workflow/. -A number of submodules are nested under the main ``land-offline_workflow`` directory. -When the ``release/public-v1.0.0`` branch of the ``land-offline_workflow`` repository +The main repository for the Land DA System is named ``land-DA_workflow``; +it is available on GitHub at https://github.com/ufs-community/land-DA_workflow. +A number of submodules are nested under the main ``land-DA_workflow`` directory. +When the ``develop`` branch of the ``land-DA_workflow`` repository is cloned with the ``--recursive`` argument, the basic directory structure will be similar to the example below. Some files and directories have been removed for brevity. +Directories in parentheses () are only visible after the build step. .. code-block:: console @@ -103,10 +104,12 @@ similar to the example below. Some files and directories have been removed for b ├── test ├── ufs-land-driver │ └── ccpp-physics + ├── (ufs-weather-model) ├── vector2tile ├── CMakeLists.txt ├── README.md ├── LICENSE + ├── check_* ├── do_submit_cycle.sh ├── release.environment ├── settings_DA_* @@ -126,7 +129,7 @@ the UFS Land DA System. +--------------------------+-----------------------------------------+------------------------------------------------------+ | Repository Name | Repository Description | Authoritative repository URL | +==========================+=========================================+======================================================+ - | land-DA_update | Contains scripts and components for | https://github.com/NOAA-EPIC/land-DA_update | + | land-DA_update | Contains scripts and components for | https://github.com/ufs-community/land-DA/ | | | performing data assimilation (DA) | | | | procedures. | | +--------------------------+-----------------------------------------+------------------------------------------------------+ @@ -147,3 +150,15 @@ the UFS Land DA System. | | UFS atmospheric model. | | +--------------------------+-----------------------------------------+------------------------------------------------------+ +The UFS Land Component +========================= + +The UFS Land DA System has been updated to build the UFS Noah-MP land component as part of the build process. +Updates allowing the Land DA System to run with the land component are underway. + +The land component makes use of a National Unified Operational Prediction Capability (:term:`NUOPC`) cap to interface with a coupled modeling system. +Unlike the standalone Noah-MP land driver, the Noah-MP :term:`NUOPC cap` is able to create an :term:`ESMF` multi-tile grid by reading in a mosaic grid file. For the domain, the :term:`FMS` initializes reading and writing of the cubed-sphere tiled output. Then, the Noah-MP land component reads static information and initial conditions (e.g., surface albedo) and interpolates the data to the date of the simulation. The solar zenith angle is calculated based on the time information. + + + +