This is Balaji's index page on FMS. The main GFDL page on FMS is here.

The links at left contain various design notes and explanations on FRE. The links at right are from my "FMS blog": there you can follow the various design and implementation issues as they arise.

The basis of FMS is component-based design. In essence, the model code is distributed into a hierarchy of self-contained units, packages, or modules.

Component terminology

• A model code is composed of a hierarchy of components.
• The hierarchy is often described by a parent-child metaphor: a component can have children whom it calls. For instance, a coupled model may have an atmosphere, ocean, and so on as its children.
• A component is self-contained, in that it can be checked out and mus compiled on its own; it can read and write its own restarts. Of

  course, since a component may call its children, it has those dependencies. In F90 in particular, these imply that parents can be compiled only after children: mkmf is a tool for creating Makefiles that generate compilations that follow these dependencies.

• Components in general come with a solo driver, that can be used to run a component more or less in isolation, except for its minimal dependencies. For instance, many of our atmospheric dycore components have a solo driver than runs a Held-Suarez experiment. Solo drivers are also a basis for unit tests.
• Components on the same level of the hierarchy ("siblings") may be on independent grids. Generally children inherit a parent's grid. Similarly, siblings may be capable of running concurrently (depending on the coupling algorithm) on independent sets of processors: generally children run within the pelist of the parent.
• In ensemble mode (currently not available for general use) several instances of a component are run concurrently within the same executable, as siblings.
• A generic component is one for which multiple choices of component may be available. For instance, FMS-based coupled models may have a generic land component, for which lad and lad2 are available choices for an actual component. In general, only one of the available choices is invoked in one model composition; though I suppose we could conceive of a heteregeneous composition when in ensemble mode.
• A generic component involves a set of interfaces and conventions, which all actual components seeking to slot in must be conformant with. For instance, all atmospheric dynamical cores have top-level routines such as atmosphere_init, update_atmosphere and atmosphere_end, and a derived type for its boundary state of type atmos_data_type. There are also conventions at the other end: they all invoke the atmospheric physics generic component following the conventions of physics_driver. A key difference between FMS and ESMF is that ESMF provides a generic component interface that is shared by all components, regardless of their role and position in the hierarchy.
• The FMS infrastructure shared and superstructure coupler are components like any other.

We have developed a component hierarchy within FMS in which a panoply of models, from idealized solo models to comprehensive Earth system models, can be built out of FMS components.