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
config.yaml
: used bypayu
for model setup and run (YAML format)datm_in
: sets stream-independent data atmosphere parameters (in Fortran namelist format)datm.streams.xml
: sets input files and other stream-dependent input data for data atmosphere in this XML formatdiag_table
: MOM6 diagnostics in this format; may be generated from adiag_table_source.yaml
YAML file bymake_diag_table.py
drof_in
: sets stream-independent data runoff parameters (in Fortran namelist format)drof.streams.xml
: sets input files and other stream-dependent input data for data runoff in this XML formatdrv_in
: NUOPC parameters for the driver (in Fortran namelist format)fd.yaml
: NUOPC field dictionary (YAML format) read by the NUOPC driver; defines standard metadata for fields that may be available for import and/or export from model components;standard_name
s are used for field pairing during initialisationice_in
: CICE6 parameters (in Fortran namelist format)input.nml
: a few MOM6 parameters (in Fortran namelist format)MOM_input
: most of the MOM6 parameters, in this formatMOM_override
: more MOM6 parameters in this format, overriding things inMOM_input
nuopc.runconfig
: read by NUOPC driver; supplies driver-related parameters for model components; parameters documented here; the file is a mix of Resource File and Fortran namelist formatsnuopc.runseq
: read by NUOPC driver; defines model component run sequence using this syntax
Where to set parameters
Model executable
exe
inconfig.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 theDebug
versions for production runs as they are much slower.
Coupling
- active model components
component_list
and entries inALLCOMP_attributes
section innuopc.runconfig
, e.g.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) ...
- components and fields to couple
- See the coupling architecture here
- 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).
- the coupling between components is recorded in the mediator log output file:
grep -A 9 "Active coupling flags" archive/output000/log/med.log
- the mediator log output file also lists the individual fields that are coupled and where the coupled fluxes are calculated:
grep '^ mapping' archive/output000/log/med.log
; see here for how to decode this
- the coupling between components is recorded in the mediator log output file:
- also see
wav_coupling_to_cice
innuopc.runconfig
- remapping/redistribution method for coupled fields
- 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 datm.streams.xml
anddrof.streams.xml
specify<mapalgo>bilinear</mapalgo>
but there are better options - see here and hererof2ocn_ice_rmapname
androf2ocn_liq_rmapname
inMED_attributes
innuopc.runconfig
*map*
inMED_attributes
innuopc.runconfig
remapMethod
innuopc.runseq
; options areredist
,bilinear
(the default),patch
,nearest_stod
,nearest_dtos
,conserve
. For strict bit-for-bit reproducibilitysrcTermProcessing=1
andtermOrder=srcseq
are also required. See details here and here and this detailed explanation.- time interpolation of coupled fields
- specified via
tintalgo
indatm.streams.xml
anddrof.streams.xml
- see here for options
Processor layout - see here
- entries in
PELAYOUT_attributes
section innuopc.runconfig
- may need to adjust
max_blocks
inice_in
- may need a
mem: 192GB
entry inconfig.yaml
if you are using less than a full node
IO layout
- entries in
*_modelio
sections innuopc.runconfig
- for
pio_typename
.- Use
netcdf4p
for parallel IO. Don't usenetcdf4c
(deprecated) orpnetcdf
(not included in dependencies). netcdf
only uses one PE (pio_root
) for IO
- Use
- MOM6 uses FMS for IO and doesn't use the settings in the
OCN_modelio
section. Instead, IO settings can be configured in thefms2_io_nml
namelist group ininput.nml
case name
case_name
inALLCOMP_attributes
innuopc.runconfig
grids
mesh_atm
,mesh_ice
,mesh_ocn
inALLCOMP_attributes
innuopc.runconfig
mesh_rof
inROF_attributes
innuopc.runconfig
- grid dimensions
*_nx
,*_ny
inMED_attributes
innuopc.runconfig
coupling diagnostics
*budget*
inMED_attributes
innuopc.runconfig
hist*
inMED_attributes
innuopc.runconfig
histaux_*_flds
is either a colon-delimited list of fields to output, orall
to output everything; see CMEPS field naming convention to decode thesegrep hist archive/output000/log/med.log
will show you when data was written
verbosity in NUOPC log files (archive/output*/log/*.log
)
Verbosity
in attributes for model components innuopc.runconfig
; can beoff
,low
,high
,max
- see here - but doesn't seems to make any difference, perhaps due to this issue.
calendar
calendar
inCLOCK_attributes
innuopc.runconfig
; can be eitherNO_LEAP
orGREGORIAN
- also set
use_leap_years = .true.
inice_in
for Gregorian calendar
start date
start_ymd
inCLOCK_attributes
innuopc.runconfig
run length
stop_n
andstop_option
inCLOCK_attributes
innuopc.runconfig
; available units forstop_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 innuopc.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
restart_n
andrestart_option
inCLOCK_attributes
innuopc.runconfig
; available units forrestart_option
are listed here
timesteps
- there is a complex set of interrelated timesteps - see here and here to understand how they interact
- coupling and driver timesteps - see here
*_cpl_dt
inCLOCK_attributes
innuopc.runconfig
nuopc.runseq
- MOM6 timestepping - see 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 inice_in
- see here) ndtd
inice_in
sets the number of dynamic timesteps in each thermodynamic timestep; increasing this can resolve "bad departure points" CFL errorsndte
inice_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
walltime
inconfig.yaml
number of ensemble members
ninst
inPELAYOUT_attributes
innuopc.runconfig
forcing data
- see the Forcing page
- atmospheric forcing
datm.streams.xml
sets individual file paths relative to this entry in theinput
section ofconfig.yaml
; see DATM and streams docs
- runoff
drof.streams.xml
sets individual file paths relative to this entry in theinput
section ofconfig.yaml
; see DROF and streams docs
See also
- ACCESS-NRI fork of CESM: https://github.com/ACCESS-NRI/CESM - see here
- MOM6 in CESM: https://github.com/ESCOMP/MOM_interface/wiki
- Shuo Li's WW3-MOM6-SIS2 FMS-coupled model configuration https://github.com/shuoli-code/MOM6_WW3_SIS2_coupled