next up previous contents
Next: 2 Running the Coupler Up: users_guide Previous: Contents   Contents


1 Introduction

1.1 Purpose of this document

CCSM components typically are accompanied by three types of documents:

1) A User's Guide -- information about how do compile and execute the code
2) A Code Reference -- information about source code and how to do source code 
3) A Scientific Description -- information about the physical and numerical
   equations, algorithms, and constants that the source code implements.

This document combines the content of all three documents for the CCSM
Coupler component.  Similar documents exist for the CCSM's atmosphere, land,
ocean, and sea-ice components.  Also, there is a CCSM User's Guide which 
explain how to compile and execute the CCSM system as a whole.

1.2 What is a "coupler'' ?

The CCSM coupled model is a framework that divides the complete climate system 
into component models connected by a coupler.  In this design the Coupler
is a hub that connects four component models -- atmosphere, land, ocean, and 
sea-ice (see Figure 1).  Each component model is connected to the Coupler, and
each exchanges data with the Coupler only. From a software engineering point of
view, the CCSM is not a particular climate model, but a framework for building 
and testing various climate models for various applications. In this sense, 
more than any particular component model, the Coupler defines the high-level 
design of CCSM software.

Figure 1: The CCSM Coupled Model Framework in its most basic form.
\begin{figure}\epsfxsize =1.5in
\centerline{\epsfbox{fig_framework.eps} }\end{figure}

The Coupler code has several key functions within the CCSM framework: 

o It allows the CCSM to be broken down into separate components, atmosphere, 
  sea-ice, land, and ocean, that are "plugged into" the Coupler. Each component 
  model is a separate code that is free to choose its own spatial resolution
  and time step. Individual components can be created, modified, or replaced 
  without necessitating code changes in other components. CCSM components run 
  as separate executables communicating via message passing (MPI).

o It controls the execution and time evolution of the complete CCSM by 
  synchronizing and controlling the flow of data between the various components.

o It communicates interfacial fluxes between the various component models while
  insuring the conservation of fluxed quantities. For certain flux fields, it 
  also computes interfacial fluxes based on state variables.  In general, the 
  Coupler allows any given flux field to be computed once in one component, 
  this flux field is then routed through the Coupler so that other involved 
  components can use this flux field as boundary forcing data.

1.3 Major considerations in Coupler functionality

The design of the Coupler and the CCSM modeling framework were motivated by a 
variety of scientific and software design issues.  Following are some of the
major design and functionality considerations which addressed the deficiencies 
of standard coupling strategies at the time of Coupler's inception (circa 1991),
and which have continued to be important considerations.

(a) System decomposition and component model code independence.

  The CCSM coupling strategy and the Coupler component (see Figure 1) allows an
  intuitive decomposition of the large and complex climate system model.  
  To a large extent, the separate component models, atmosphere, sea-ice, land, 
  and ocean, can be designed, developed, and maintained independently, and later
  "plugged into" the Coupler to create a complete climate system model.  
  At the highest design level, this creates a highly desirable design trait
  of creating natural modules (or "objects") with maximum internal cohesion and
  minimal external coupling.

(b) Control of the execution and time evolution of the system.

  The Coupler (a natural choice), rather than one of the component models (any 
  of which would be an arbitrary and asymmetrical choice), is responsible for 
  controlling the execution and time evolution of the complete system.

(c) The appropriate boundary condition for all component models are the fluxes
  across the surface interfaces.

  In terms of the climate simulation, the Coupler (originally called the "Flux
  Coupler") couples component models by providing flux boundary conditions to 
  all component models.  State variables flow through the Coupler only if 
  necessary for a flux calculation in the Coupler or a component model.

(d) Conservation of fluxed quantities.

  The Coupler can conserve all fluxed quantities that pass through it.
  Since all surface fluxes pass through the Coupler, this framework assures
  that all surface fluxes in the system are conserved.  The Coupler also can
  and does monitor flux conservation by doing spatial and temporal averages of 
  all fluxed quantities.

(e) A flux field should should be computed only once, in one component, and then
  the field should be given to other components, as necessary.

  For example, generally the resolution of the ocean component is finer than 
  that of the atmospheric component. Heat is not conserved if the atmosphere 
  component computes long wave radiation using sea surface temperature (SST) 
  averaged onto the atmosphere's grid, while the ocean component uses individual
  grid point SSTs.  This is because the flux calculation is proportional to 
  SST**4 (is non-linear) and the two calculations will yield two different 
  results .  Instead of trying to compute the same flux twice, on two different
  grids in two different components, the flux should be computed once and then 
  be mapped, in a conservative manner, to other component grids.

(f) Fluxes can be computed in the most desirable place.

  For example, when an atmospheric grid box covers both land and ocean, a 
  problem arises if fluxes are first computed on the atmospheric grid and then 
  interpolated to the ocean grid. If land roughness is significantly larger than
  ocean roughness (as is typical), and the atmosphere uses an average underlying
  roughness to compute the windstress, and then windstress is interpolated to 
  coastal land and ocean cells, windstress will be considerably lower (for land)
  or higher (for ocean) than it should be. This approach can lead to unrealistic
  coastal ocean circulations.  In this case it is more desirable to compute the
  surface stresses on the surface grids and subsequently merge and map them to 
  the atmospheric grid.  Thus this calculation should take place in either the
  Coupler, land, ice, or ocean models.

  In the case of computing precipitation, because this calculation requires full
  3D atmospheric fields, and because only 2D surface fields are exchanged 
  through the Coupler, this calculation should take place in the atmosphere 

(g) Allowing the coupling of component models with different spatial grids.

  In general it is desirable to allow the different component models to exist on
  different spatial grids.  It is also desirable that a component model need not
  be aware of, or concerned with, the spatial grids that other component models
  are using.  The Coupler handles all mapping between disparate model grids, 
  allows component models to remain unaware and unconcerned with the spatial 
  grids of other CCSM components.

  Due to scientific considerations, the current version of CCSM requires that
  the atmosphere and land components be on the same spatial grid. Because it is
  not a requirement to do so, the Coupler does not have the functionality to 
  allow the atmosphere and land to be on different grids.  Similarly, the 
  current version of CCSM requires that ocean and sea-ice components be on the 
  same grid and the Coupler does not have the functionality to allow them to be
  on different grids.

  Except as noted above, no component needs to know what spatial grid other 
  components are using.  The Coupler is responsible for all mapping between the
  various spatial grids of the various components models.  The component models
  themselves have no knowledge of what other grids are involved in the coupled 
  system and they can remain unconcerned with any issues regarding mapping 
  between grids.

(h) Allowing the coupling of models with different time steps.

  While there are some restrictions on what internal time step models are
  allowed to use (for example, there must be an integer number of time steps per
  day), the Coupler offers component models considerable freedom in choosing
  their internal time step.  Frequently all four CCSM components operate with 
  four different internal time steps.

1.4 History

The origins of the Coupler are in the Oceanography Section (OS) of the Climate 
and Global Dynamics Division (CGD) of the National Center for Atmospheric 
Research (NCAR).  While coupling the Community Climate Model (CCM2, the
atmosphere model) with a regional Pacific Basin Model for ESNO/El-Nino studies
(Gent, Tribbia, Kauffman, & Lee, 1990), it became clear that it was extremely 
awkward to couple the models by implementing the ocean model as a subroutine 
within an atmosphere model.  An idea emerged that a more desirable software 
architecture would be to have both the ocean and atmosphere models as 
subroutines to a higher-level driver/coupler program.  This "coupler" component
would reconcile the differing component model spatial grids (handle the mapping
of data fields), reconcile different time step intervals, and control when the 
coupled system would start and stop.  Thus the two component models could be 
very independent and largely unaware of the software details of the other 
components.  The modularity of this arrangement also suggested a framework in 
which, for example, it would be relatively easy to exchange one ocean component
for another.

Other OS scientists joined in (McWilliams, Large, Bryan, 1991), and together
worked out a scientific design philosophy for the Coupler and the coupled 
system, for example, that the appropriate boundary conditions for component 
models were the fluxes across the surface interfaces, that fluxes should be
conserved, and that ad hoc flux corrections were undesirable.  Frank Bryan 
suggested the models be separate executables communicating by message passing 
rather than subroutines in a single executable, this resulted in an MPMD 
implementation that proved extremely successful.

Climate Modeling Section (CMS) scientists joined the effort (Boville,, 
1992), working on the atmosphere component (CCM) so that it produced a quality 
simulation when bottom boundary conditions were fluxes instead of fixed BC's.  
The CCM was a very successful atmosphere general circulation model, a flagship 
NCAR project.  In part because of the Coupler and its associated framework, it 
now seemed plausible to use the CCM as the atmosphere component in an 
institutional coupled climate model project.

A proposal was made to NSF for a new, NCAR-wide, Climate System Model (CSM)
Project (1993), with the long-term goal of building, maintaining, and 
continually improving a comprehensive model of the climate system.  The Coupler
proto-type code and design philosophy formed the basis for CSM's software 
framework.  The CSM project was funded and formally began in 1994. 

The name, "cpl5" or "Coupler, version 5", alludes to five versions of the 
Coupler, they are:

cpl1 (Kauffman, 1990): a rough proto-type code, never released.
     Coupler is a driver program that handles all high-level control (eg. start/
     stop/advance of component models) and all mapping between grids.  The 
     complete system is a single-executable with two swappable component model 
     subroutines: ocean/ice and atmosphere/land.  Written in Fortran 77.

cpl2 (NCAR/CGD, Oceanography Section, 1992): a proto-type code, never released.
     New scientific design philosophy, does flux calculations, insures 
     conservation of fluxed quantities.  Complete system uses component models
     that are separate executables.  Uses PVM for message passing.

cpl3 (NCAR/CGD, 1996): released with CSM 1.0
     Has three component models: atmosphere/land, ocean, and ice.  First fully 
     functional version.  Uses MCL for message passing.  Uses netCDF.
cpl4 (NCAR/CGD, 1998): released with CSM 1.2
     Has four component models: atmosphere, land, ocean, and ice.  Uses MPI for
     message passing.

cpl5 (NCAR/CGD, 2002): released with CSM 2.0
     Written in Fortran 90, uses SCRIP to generate mapping data, handles shifted
     pole grids.