Example members for data types native to the topographic unit level:

• Topographic unit energy state (top_es): near-surface air temperature.
• Topographic unit water state (top_ws): near surface air absolute humidity, glacier mass (still to be resolved – maybe this is at the soil column level for V1)
• Topographic unit energy flux (top_ef): incident shortwave radiation (direct and diffuse, visible and near IR), incident longwave radiation, outgoing shortwave (visible and near IR), outgoing longwave, latent heat flux, sensible heat flux. Placeholder for energy transported to the ground in precipitation. Momentum flux and wind speed should ideally have their own data structures, but it may be more convenient for now to leave them with the energy fluxes. In earlier CLM versions all the atmospheric forcing data were lumped together in the atm2lnd structure. As the connections between atmosphere and land become more sophisticated, it may be helpful to initiate a more regular system for keeping track of those interface states and fluxes, as suggested here.
• Topographic unit water flux (top_wf): precipitation amount (and form as rain, snow, mixed), condensation, evaporation, transpiration. Although latent heat flux is already accounted in the top_ef structure, it will be helpful to account explicitly for the gross exchanges of water mass.
• Topographic unit physical properties (top_pp): area, mean elevation, slope, and aspect. Albedo (for direct and diffuse, visible and near IR), emissivity. Roughness length for momentum transfer. Elevation angles of horizon in several cardinal directions. ID of parent gridcell. Number, type, and IDs of child landcover units.

Date last modified: 13 Sep 2015  
Contributors: Peter Thornton

General points related to software implementation:

• In contrast to the deeply nested data types used in CLM4 (where most types were defined as members of a single foundational type), the proposed implementation has multiple foundational types, avoiding multiple levels of pointer indirection.
• The non-ED implementation will use the allocatable pointer architecture for data types common in both r085 and r097 tags of CLM4.5. The ED implementation can use dynamically allocated lists using the proposed architecture, without changing its basic memory management approach.
• In contrast to the CLM4.5 implementations, the proposed architecture has separate types for variables at each level of the sub-grid hierarchy. In CLM4.5 the variable name itself is used to identify the level of the sub-grid hierarchy to which it applies (e.g. waterstate_type%h2ocan_patch for patch-level canopy intercepted water). The proposed data types would intrinsically define the relevant sub-grid level (e.g. veg_ws%h2ocan for cohort-level canopy intercepted water).
• To the extent that different data type organizations are required to meet the needs of individual subroutines or model capabilities, those types can be constructed easily as collections of pointers to the foundational types. In some cases it may be necessary to have copies of constructed data types (for example to make use of GPUs, or where the deeply nested pointer arrangement of linked lists for ED implementation is causing performance issues), in which case new space allocation and copying from foundational types is also easily supported.
• The foundational types ensure that new variables added during the development process are introduced in a logical part of the sub-grid hierarchy, and that mass and energy balance can be readily verified and maintained across multiple sub-grid levels. They also make it simple to swap model functionality at logical component boundaries. For example, a new soil column representation or a new vegetation cohort representation can be introduced and evaluated easily against existing module as long as the between-level interface variable naming and meaning is maintained.