Skip to content

Configurations

Jump to bottom
Anton Steketee edited this page Dec 10, 2024 · 75 revisions

CMEPS-coupled configurations

ACCESS-OM3 configurations are provided via branches in these repositories. They all have prescribed data atmosphere and runoff.

  • access-om3-wav-configs: 3-way coupled MOM6-CICE6-WW3 ocean, sea ice and waves
  • access-om3-configs: 2-way coupled MOM6-CICE6 ocean and sea ice (no waves)
  • CICE6-WW3: 2-way coupled CICE6-WW3 sea ice and waves (prescribed data ocean), not currently working

Overview of the CMEPS configurations

The three CMEPS-coupled configurations have much in common. Here we provide a quick overview of the common features, using examples from the 1deg_jra55do_ryf branch of access-om3-configs (i.e. MOM6-CICE6).

What the configuration files are for

Where to set parameters

  • model executable
    • exe in config.yaml. Pre-built executables are available in /g/data/ik11/inputs/access-om3/bin/ or you can build your own. Executable names indicate the available model components and the git hash of the source code used. Avoid using the Debug versions for production runs as they are much slower.
  • active model components 
component_list: MED ATM ICE OCN ROF
ALLCOMP_attributes::
     ATM_model = datm  # data atmosphere
     GLC_model = sglc  # no glaciers/land ice (stub)
     ICE_model = cice  # active sea ice (cice)
     LND_model = slnd  # no land model (stub)
     MED_model = cesm  # mediator
     OCN_model = mom   # active ocean model (mom6)
     ROF_model = drof  # data runoff
     WAV_model = swav  # no wave model (stub)
     ...

  • fields to couple

    • Coupling is negotiated between model components during initialization of a model run. See here: "CMEPS advertises all possible fields that can be imported to and exported by the mediator for the target coupled system. Not all of these fields will be connected to the various components. The connections will be determined by what the components advertise in their respective advertise phase."
    • fd.yaml: NUOPC field dictionary defines standard metadata for fields that may be available for import and/or export from model components; standard_names are used for field pairing during initialisation
    • the fields available to be imported/exported for coupling are determined by the NUOPC cap code for MOM6, CICE6, WW3, DATM and DROF and recorded in the mediator log output file: grep Advert archive/output000/log/med.log
    • whether those fields are actually coupled is determined by the CMEPS mediator at run time (see here) and recorded in the mediator log output file: grep -A 9 "Active coupling flags" archive/output000/log/med.log
    • also see wav_coupling_to_cice in nuopc.runconfig

  • remapping/redistribution method

    • datm.streams.xml and drof.streams.xml specify <mapalgo>bilinear</mapalgo> but there are better options - see here and here
    • rof2ocn_ice_rmapname and rof2ocn_liq_rmapname in MED_attributes in nuopc.runconfig
    • *map* in MED_attributes in nuopc.runconfig
    • remapMethod in nuopc.runseq; options are redist, bilinear (the default), patch, nearest_stod, nearest_dtos, conserve. For strict bit-for-bit reproducibility srcTermProcessing=1 and termOrder=srcseq are also required. See details here and here and this detailed explanation.
    • The remapping method used for each field is recorded in the mediator log output file: grep '^ mapping' archive/output000/log/med.log; see here for how to decode this

  • time interpolation of coupled fields

  • Processor layout - see here

    • entries in PELAYOUT_attributes section in nuopc.runconfig
    • may need to adjust max_blocks in ice_in
    • may need a mem: 192GB entry in config.yaml if you are using less than a full node

  • IO layout

    • entries in *_modelio sections in nuopc.runconfig
    • for pio_typename.
      • Use netcdf4p for parallel IO. Don't use netcdf4c (deprecated) or pnetcdf (not included in dependencies).
      • netcdf only uses one PE (pio_root) for IO
    • MOM6 uses FMS for IO and doesn't use the settings in the OCN_modelio section. Instead, IO settings can be configured in the fms2_io_nml namelist group in input.nml

  • case name

    • case_name in ALLCOMP_attributes in nuopc.runconfig

  • grids

  • coupling diagnostics

  • verbosity in NUOPC log files (archive/output*/log/*.log)

    • Verbosity in attributes for model components in nuopc.runconfig; can be off, low, high, max - see here - but doesn't seems to make any difference, perhaps due to this issue.

  • calendar

    • calendar in CLOCK_attributes in nuopc.runconfig; can be either NO_LEAP or GREGORIAN
    • also set use_leap_years = .true. in ice_in for Gregorian calendar

  • start date

    • start_ymd in CLOCK_attributes in nuopc.runconfig;

  • run length

    • stop_n and stop_option in CLOCK_attributes in nuopc.runconfig; available units for stop_option are listed here

  • run sequence

    • The order which components are run is specified in nuopc.runseq. The order also impacts whether components run sequentially or in parallel. Normally we specify CICE and MOM to run in subsequent lines in nuopc.runseq, and as long as they are on different processors, they run in parallel as these steps do not depend on each other.
    • To run MOM before CICE, specify all OCN related steps in the nuopc.runseq before all ICE related steps (see example here). This will be very slow and resource inefficient and is for testing / debugging only. It does reduce the coupling related lag in stress between the sea-ice and ocean (see Morrison 2024 slides

  • restart frequency

  • timesteps - there is a complex set of interrelated timesteps - see here and here to understand how they interact

    • coupling and driver timesteps - see here
    • MOM6 timestepping - see here
      • There are 4 timesteps. From shortest to longest they are: barotropic, baroclinic (Lagrangian), tracer, vertical remapping - see here and here and here
    • CICE6 timestepping - see here
      • There are 3 timesteps. From shortest to longest they are elastic, dynamic and thermodynamic - see here
      • The thermodynamic timestep is determined by the coupling (and driver) timestep (so dt should not be explicitly set in ice_in - see here)
      • ndtd in ice_in sets the number of dynamic timesteps in each thermodynamic timestep; increasing this can resolve "bad departure points" CFL errors
      • ndte in ice_in sets the number of elastic timesteps in each dynamic timestep if the classic EVP or EAP method is used (kdyn = 1 or 2, revised_evp = false)

  • walltime limit

  • number of ensemble members

    • ninst in PELAYOUT_attributes in nuopc.runconfig

  • forcing data

See also

Clone this wiki locally