This web page contains links to documentation, source code, and input data for the stand-alone version release of CLM2.1. Links to the CAM2.0.1 (Community Atmosphere Model) stand-alone version release and coupled CCSM2.0.1 (Community Climate System Model) release can be found at the bottom of the page. !!NOTE!!: This code currently does not work with CAM2.0.1, however, a new release of CAM (CAM2.0.2) incorporating CLM2.1 is imminent.
CLM2.1 incorporates new hierarchical subgrid data structures and produces only roundoff level changes when compared to CLM2.0.
In what follows, we provide a brief summary of the new CLM2.1 data structures. The subgrid hierarchy in CLM2.1 is composed of gridcells, landunits, columns and plant functional types (pfts). Each gridcell can have a different number of landunits, each landunit can have a different number of columns and each column can have multiple pfts. This results in efficient memory allocation, and allows for the implementation of many different types of subgrid representation.
The first subgrid level, the landunit, is intended to capture the broadest spatial patterns of subgrid heterogeneity. These broad patterns include the physically distinct surface types that were treated as special cases in the previous versions of CLM2.0 (e.g. glaciers and lakes). In terms of CLM2.0 variables, the central distinguishing characteristic of the landunit subgrid level is that this is where physical soil properties are defined: texture, color, depth, pressure-volume relationships, and thermal conductivity. In CLM2.1, landunits are used to represent the special landcover types (e.g. glacier and lakes), with a single additional landunit for the gridcell vegetated area.
The second subgrid level, the column, is intended to capture potential variability in the soil and snow state variables within a single landunit. The central characteristic of the column subgrid level is that this is where the state variables for water and energy in the soil and snow are defined, as well as the fluxes of these components within the soil and snow. Regardless of the number and type of pfts occupying space on the column, the column physics operates with a single set of upper boundary fluxes, as well as a single set of transpiration fluxes from multiple soil levels. These boundary fluxes are weighted averages over all pfts.
The third and final subgrid level is referred to as the plant functional type (pft), but it also includes the treatment for bare ground. It is intended to capture the biophysical and biogeochemical differences between broad categories of plants, in terms of their functional characteristics. All fluxes to and from the surface are defined at the pft level, as are the vegetation state variables (e.g. vegetation temperature, canopy water storage, and carbon and nitrogen states for the leaf, stem, and roots).
In addition to state and flux variable data structures for conserved components at each subgrid level (energy water, carbon, nitrogen, etc.), each subgrid level also has a physical state data structure for handling quantities that are not involved in conservation checks (diagnostic variables). For example, soil texture is defined through physical state variables at the landunit level, the number of snow layers and the roughness lengths are defined as physical state variables at the column level, and the leaf area index and the fraction of canopy that is wet are defined as physical state variables at the pft level.
This subgrid hierarchy is implemented in CLM2.1 as a set of nested derived types. Extensive use is made of pointers, both for dynamic memory allocation and for simplification of the derived type referencing within subroutines. The use of pointers for dynamic memory allocation ensures that the number of subgrid elements at each level in the hierarchy is flexible and resolved at run time, thereby eliminating the need to statically declare arrays of fixed dimensions that might end up being sparsely populated. The use of pointers for referencing members of the derived data type within the subroutines provides a coherent treatment of the logical relationships between variables (e.g., the user cannot inadvertently change a pft-level variable within a subroutine that is supposed to operate on the column states and fluxes), and a more transparent representation of the core algorithms (it is easy to tell when the code is in a column or pft loop).