Skip to content

Milestone: CMEPS 0.6

Rocky Dunlap edited this page May 14, 2020 · 8 revisions

DRAFT Milestone - Page in Progress

Overview

In this milestone, the Community Mediator for Earth Prediction Systems (CMEPS) is used to couple the model components in NOAA's Unified Forecast System (UFS) Subseasonal-to-Seasonal (S2S) application. The model components included are the UFS Atmosphere, the Modular Ocean Model (MOM6) and the Los Alamos sea ice model (CICE5).

Changes Since CMEPS 0.5

A description of the previous milestone (CMEPS 0.5) is available on the UFSCOMP wiki. That site is deprecated since it was set up for prototyping purposes before the UFS S2S was brought to GitHub.

This section lists the improvements since the previous milestone:

  • Code:

    • All component code is on GitHub in authoritative UFS repositories, pointing to develop or master branches - previously some code, e.g., FV3GFS was in private repositories
    • CMEPS has been fully integrated as a Mediator option side-by-side with the NEMS Mediator to support a transition period and comparison of CMEPS against the NEMS Mediator
  • Driver:

    • S2S is running with the NEMS driver (same as used by all UFS applications), whereas in the previous version it was running with the CIME driver
  • FV3:

    • fractional branch was merged into develop branch
    • no longer use mediator calculated fluxes - NEMS Mediator was giving mixed ocean/ice flux - this has been removed completely
  • CICE5:

    • S2S is running with EMC's CICE5 whereas the previous milestone was running with CICE5 from NCAR - the NUOPC caps were significantly different and there were some different science options
  • CMEPS:

    • application-specific fields exchange specification (esmFldsExchange_nems.F90) and YAML NUOPC field dictionary - this permits independent expression of coupling exchanges and mapping for each application using CMEPS - removed a lot of extra "if" logic when it was combined - easier to read and document
    • the configuration file (nems.configure) has been greatly simplified, removing all of the unused attributes - read by the nems driver and passed to CMEPS by the driver
  • Restarts:

    • Previous version may not have been warm-start reproducible (need to check git logs)
    • Previous version did not support restarting the coupled system, except for a special sequence ("cold 2") which used the same initial conditions as the cold-start except the mediator read in an initial set of fluxes
    • Full restart of the coupled system is now working with UFS Atmosphere, MOM6, CICE5, and CMEPS. This means that a continuous run gives the same history file output, for all components of the coupled system, as a run with a restart in the middle. Major changes to enable reproducible restarts include:
      • A halo decomposition bug was found in MOM6 - on restart the signature of the grid decomposition was visible in model fields, e.g., temperature - the workaround was to turn off a Langmuir mixing parameterization; GFDL is looking into the actual source of the halo decomposition bug
      • Updates to CICE: CESM's shortwave routine was swapped in to the EMC CICE5 - this was leading to an issue with ice albedo not reproducing within the first timestep; halo regions were added to the restart file and read in during restart

Limitations/Known Bugs

  • The CIME workflow was available in the CMEPS 0.5 milestone but is not supported for this release. This is due to (1) switching from NCAR's CICE5, which is CIME compliant to EMC's CICE5, which is not CIME compliant; and (2) moving to the ufs-community/ufs-s2s-app repository on GitHub, which has not been set up with any workflow.
  • CMEPS is fully conservative, although this configuration has not been tested yet within S2S.
  • WaveWatch3 is included in the S2S application, but has not yet been thoroughly tested. It is currently one-way coupled to the UFS Atmosphere. (Waves two-way coupled will be used for next benchmark, but wave model is currently breaking reproducibility of restarts.)

Supported Platforms

Download, Build, and Run

Validation

Notes

  • Common platform was critical (Cheyenne)
  • Ability to move history write in the run sequence allows for flexible debugging of model fields and to identify where reproducibility problems originate
  • The cprnc utility was critical