...
At a runtime-selectable frequency, each component will communicate with the coupler and send it a list of data. At the same frequency, but at possibly a different place in the component's call sequence, it will receive data from the coupler
Explicit integration sequence
...
with atmosphere-ocean described:
The driver calls each model's run method and the various coupler functions in a fixed sequence. The driver code allows for a few slightly-different sequences that can be selected at runtime using the CPL_SEQ_OPTION in env_run.xml. The sequence used by E3SM in coupled runs is RASM_OPTION1 and illustrated below:
...
When the ocean finishes, it waits for the driver to call a method that transfers all the needed ocean data back to the coupler (the horizontal line going from "Ocn Run" and pointing to the left). If the driver gets to this method before the ocean is finished, the union of coupler and ocean tasks will wait. (Load balancing in the coupled model tries to allocate processors to components to minimize this wait time.)
Meanwhile, after the driver calls the ocean's run method, it can still do things on the non-ocean tasks. It receives data from other components (land, sea-ice). When the driver calls "Atm Prep" on the coupler processors, "Atm Prep" will have all the data from other components that has been transferred to the coupler (in MCT datatypes). It will perform any interpolation necessary to put that data on the atmosphere grid. It will then merge the input from multiple surface components so each atmosphere grid point has a single value for heat, water, momentum flux. The driver will then transfer the data to the atmosphere (on the union of atmosphere-coupler processors).
...
Each model can set its internal time step(s) through its Fortran namelist (or MPAS stream). For example "dtime" in the atmosphere might be set to 1800 seconds (30 minutes).
How often each component sends/receives data to/from the coupler is first determined by the NCPL_BASE_PERIOD. This is almost always 1 day and is set in env_run.xml.
The coupler communication frequency is an integer number of times per NCPL_BASE_PERIOD. The atmosphere's coupling frequency is NCPL_ATM. The frequency depends on the component set and the grid and the options are in the driver's config_component.xml seen in https://github.com/E3SM-Project/E3SM/blob/master/cime/src/drivers/mct/cime_config/config_component_e3sm.xml.
In a fully coupled case, the NCPL_ATM =48. With a base period of 1 day, the atmosphere communicates with the coupler very 30 simulated minutes. When dtime is also 30 minutes (typical for ne30 cases), the the atmosphere communicates with the coupler every atmosphere time step.
Making sure stable combinations of timesteps and coupler frequency is available out-of-the-box is up to the model developer. For example, the dtime for ne120 cases is set to 900 seconds (15 minutes) in https://github.com/E3SM-Project/E3SM/blob/master/components/cam/bld/namelist_files/namelist_defaults_cam.xml and the coupler frequency is set to 96 times per day (15 minutes).
The driver contains code for time averaging the data to be sent to a component if the coupler frequencies don't match. For example if NCPL_OCN is set to 3 hours while the NCPL_ATM is 1 hour, the coupler will accumulate the atmosphere ocean fluxes calculated every time the atmosphere talks to the coupler and send the ocean the average. Not all component pairs can be different. The driver assumes the atmosphere, land and sea-ice all have the same coupler frequency.
Coupling Fields