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 modifications 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.
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.
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.
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 component. (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.
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, et.al.,
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.