Next: 3 Review Status
Up: cpl6_reqdoc
Previous: 1 Synopsis
Contents
Subsections
The coupler steers the execution of the components of the CCSM, and coordinates and supports the transfer
of data between the components. Each component model is unaware of the timestep or
grid used by the other
component models, and the component models communicate only through the coupler at a specified communication
interval.
The coupler's interfaces to the component models must be well defined, such that existing component models
can be swapped for new models, or benign substitutes, in a reasonably straightforward manner.
The coupler must allow the user to modify (add/delete/change) the types and amounts of data which are being
exchanged between the coupler and the component models, or add a new model to the configuration, with minimal
changes to the coupler code.
2.1.4 Time Stepping Method
The coupler is required to support either process split or time split
advancement of the component models.
This requirement is closely associated with the requirement contained in Section 2.2.5.
- Fluxes
The coupler is required to compute and combine interfacial fluxes, as needed, among the various component models.
- Mapping
The coupler must perform the necessary mapping operations required to transform data between different component
model grids. Each individual component model is unaware about the grid structures of the other
component models. When mapping fluxes, conservation must be insured (using the
LANL SCRIP package
or similar software).
- Merging
When data is being prepared for a destination grid, the coupler must be able to merge (spatially average)
data originating from multiple source grids. For example, a flux to the atmosphere, within an
atmospheric grid cell, may be composed of a combination of the flux from the land, sea ice, and ocean models.
- Time-Accumulation and Time-Averaging
The coupler must be able to do time accumulation and time averaging of data during the integration for
subsequent distribution to other component models. This may be necessary for flux conservation when different
models use different communication intervals.
- Diagnostics
The coupler must be able to perform and report basic diagnostic calculations, such as spatial and temporal
averages of the quantities exchanged between component models.
The coupler is required to support general grid shapes (not just logically rectangular grids). The coupler must
have the ability to work around masked areas.
2.1.7 Fault Detection
The coupler must perform an initial coherence check to insure that all component models are set-up in the proper
manner for the expected integration. The coupler must allow periodic coherence checks to assure proper
synchronization. In situations where the component models fail, the coupler is required to have a mechanism to
detect the failure and shutdown the entire system.
The target platform for the coupler design will be clusters of RISC based multiprocessors. This architecture is a
superset of traditional one processor per node MPPs (Cray-T3E) and large scalable shared memory systems
(SGI Origin 2000). Examples of such clusters include the IBM SP and Compaq ES-40 clusters. Achieving high
performance on both vector and RISC processors is complicated. Experience has shown that in many
circumstances redundant pieces of code must be generated, which will necessarily slow the coupler development
effort. Therefore, the goal of achieving efficient vector processing performance,
although desirable, is not a requirement at this time.
All of the general purpose libraries written for the coupler are required to have a Fortran 90 API or a Fortran 90
module interface. All physics packages written explicitly for the coupler are required to be written in
Fortran 90.
2.2.3 Parallel Implementation
The coupler is required to give the user control in selecting pure message passing, pure shared memory
multithreading, or hybrid parallel algorithms to take advantage of different platforms and
the relative performance of parallel modes on those platforms.
Under certain conditions, bit-for-bit reproducibility is required under the different parallel
implementations listed in Section 2.2.3. At a minimum the coupler must give bitwise reproducibility
when a statically loaded executable (same model with identical linked libraries) is rerun on the same machine
at the same site on the same number of processors. It is noted that a strict requirement for bitwise parallel
reproducibility may have a negative impact on performance.
2.2.5 Sequencing
The coupler functions will support both sequential and concurrent execution of the component models, in a
fashion such that the user can configure the model/coupler with the sequencing method which makes
the most sense for a particular problem/platform. This requirement is closely associated with the requirement
contained in Section 2.1.4.
At a minimum the coupler is required to meet or exceed the performance of the current (March 2000)
Climate System Model, Version 1.2
and
Parallel Climate Model, Version 1.0
when configured
(component model resolutions and communication intervals) similarly. That is, for concurrent execution, the
coupler must at least outperform the most time intensive component model in terms of seconds per model day; for
sequential execution, the coupler must not comprise more than 20% of the entire CCSM execution time.
It is noted that the user can select a model/coupler configuration which easily can violate this requirement
(such as configuring a shorter coupling interval requiring more
mappings and communication).
The coupler is required to accommodate executing in an environment where
the coupler and the component models comprise a single executable, or
where the coupler and each component model run as separate executables.
It is worth noting that single vs. multiple executables is independent of the sequencing method
selected (e.g., concurrent execution can be accomplished with a single executable).
For flexibility, the coupler must be capable of running decomposed into an arbitrary numbers of processors. This
is transparent to the component models.
Only communications between the coupler and the component models are allowed. Component model to
component model communications are disallowed. Functionally, n coupler nodes should be able to communicate
in parallel with m model nodes, for an arbitrary (n,m). Parallel communications between coupler and component
models should be explored, developed and optimized, if possible.
The regridder must be capable of performing arbitrary regriddings; i.e., any mapping from a source grid vector into
a destination grid vector, representable by a transformation matrix, should be supported. The regridder must be
capable of performing fast, efficient regriddings in parallel either through threading, or message passing, or both.
The regridder must be able to perform a masked regridding operation.
The coupler must be able to read/write restart datasets that insure CCSM bit-for-bit restartability, and write
history datasets consisting of user selected sets and subsets of data being exchanged between the component
models. If possible, the NCAR/Unidata I/O Library
will be used.
Similar to the scientific functionality requirement in Section 2.1.7, the coupler is required to have a
mechanism which will recognize in a rudimentary fashion that a fatal computational problem has arisen and perform the
necessary operations to shutdown the entire model system.
In order to meet the desired requirements of the coupler, it is apparent that the component models will need to
have a priori knowledge of, and must be able to fulfill, some coupler requirements. A list of possible
requirements of the component models, imposed by the coupler requirements, is given in this section. Note that
the reverse is also true - the models may impose a requirement of the coupler. Any requirements of this latter
type are unknown at the present time, but this document recognizes and notes the possibility.
The component models are required to make accommodations for system configurations of either a single or
multiple executable running environment. Furthermore, when the system is configured as concurrently running
component models within a single executable, the component models must have the flexibility to execute within a
designated processor space.
The coupler is required to detect and/or react to a system problem, and therefore must receive appropriate fault
detection handshaking signals from the component models. Thus, the component models are required to provide
such signals. The component models may also be required to detect a coupler problem and act appropriately.
Other handshaking requirements between the coupler and the component models include:
- interface design
- on-command AUTO-restart writing capability
- possibly use the CCSM shared code (physical constants, orbital parameters, etc.)
- calendar manager
This list is certainly not all-inclusive.
Next: 3 Review Status
Up: cpl6_reqdoc
Previous: 1 Synopsis
Contents
csm@ucar.edu