CAM Reference Manual
This document was last updated on 2014-07-09 19:03:26.
Table of Contents
1. Introduction
1.1. Vision做完某事的英文
2. Coding Conventions
3. Architecture
3.1. Component Interface
3.1.1. Component Interface Documentation
3.2. Component Design
4. Physics Driver
4.1. Physics Drivers and Data Structures
4.1.1. Array dimensions
4.1.2. Precision of real data
4.1.3. Derived data types
imei码查询
5. Column Physics Packages
5.1. Overview
5.2. Requirements
6. Physics Package Utilities
6.1. Radiative Constituents
6.1.1. Ur Interface
6.1.2. Application Programmer Interface
6.1.3. U in CAM
6.2. Subcolumns
6.2.1. Subcolumn schemes
6.2.2. Subcolumn fields
6.2.3. Subcolumn usage
7. Infrastructure Utilities
7.1. CAM Grids
7.1.1. Horizontal Coordinates
References
List of Figures
3.1. Component Interface Dependencies
6.1. Radiative Constituents Module Dependencies
Chapter 1. Introduction
Table of Contents
1.1. Vision
This manual is intended for anyone who plans to get their hands dirty modifying CAM code. It is a work in progress! So despite our best intentions to provide exactly what you need to know in order to add your new science or diagnostic capability to CAM, undoubtedly we will fall short. If you don't find the information you need here, then plea post to the CESM bulletin board using the CAM forum for MAKING CHANGES TO THE SOURCE CODE .
The following list contains the topics we hope eventually.
•!coding conventions
•!CAM's high level architecture
山东兖矿技师学院•!interface design for the dynamics and physics packages
•!utilities for the dynamics and physics packages
•!driver layers
•!top level data structures for physics and dynamics
•!coupling between the physics and dynamics packages
•!infrastructure utilities (e.g., output and time management)
•!design of the configure and build-namelist utilities
1.1. Vision
CAM must produce high quality simulations for u in a wide variety of activities, for example:
•!as the atmosphere component of CESM it is ud for studying climate change and climate variability, and to produce simulations for national and international asssment activities;
•!as the atmosphere component of data assimilation systems (e.g., DART) it must make accurate weather and constituent transport
forecasts;
•!as a standalone model it is ud for rearch in the development of new dynamical cores and parameterizations of subgrid-scale physics
and chemistry.c语言课程
脾胃不和怎么调理
The u of CAM in climate rearch and asssment activities, and for data assimilation requires high performance, which must be achievable on a wide variety of computer architectures.
The u of CAM in rearch and development environments requires that its design be modular to facilitate change, and the addition of new functionality.
Chapter 2. Coding Conventions
One conquence of being a community effort is that CAM has a large and diver group of developers. We also include code that was not written specifically for CAM. Hence the contributed CAM code ba does not conform to any consistent standard, and the project has never had the resources to attempt to enforce a standard.
The purpo of coding conventions is to facilitate the production of readable, testable, and maintainable code. Taking into account the realities of how CAM's code has been developed, our approach to coding conventions is to allow considerable flexibility in matters of style, and to encourage best coding practices on matters of substance. Our current thoughts on this are maintained on this wiki page.
Chapter 3. Architecture
Table of Contents
3.1. Component Interface
3.1.1. Component Interface Documentation
3.2. Component Design
At the highest level CAM is designed to be a component in an Earth system model. This architecture requires each component to provide initialize, run, and finalize methods, along with import and export state objects designed to allow communication with other other components mediated by a coupling component. The coupling component acts as the system driver and provides capabilities su
ch as mapping between different component grids, merging from veral source components to a destination component, computation of physical quantities such as fluxes which require input from multiple components, and the computation of diagnostics. The CESM us
the CPL7 coupling component which is documented here, and described in the paper Craig et al..
The CAM component employs a modular design to provide flexibility in incorporating new dynamical cores and parameterized physics packages. The design allows the dynamical core and the physics package to u different grids and/or different grid decompositions, and us an internal dynamics-physics coupler which is independent of the high level coupler for the Earth system components. It contains a multi-level approach to the physics driver layers which facilitates supporting multiple physics packages, both new and old, from the same code ba. And it provides physics infrastructure rvices that help coordinate the actions of the various physics packages.
3.1. Component Interface
The CAM component interface is implemented in two layers. This
architecture insulates the CAM specific data structures ud by the import and export state objects fr
om the data structures ud by the coupling component. The modules that implement this design are outlined
in Figure 3.1, “Component Interface Dependencies”.
Figure 3.1. Component Interface Dependencies
Modules at the tails of the arrows depend on the modules at the heads of
小时代电影简介the arrows.训诂学
3.1.1. Component Interface Documentation
The CAM component interface is implemented in the following modules: atm_comp_mct
绿萝怎么修剪The atm_comp_mct module is a translation layer which implements the generic atmosphere component interfaces required by CPL7 using
the CAM component interfaces provided by cam_comp and
the CAM import and export state objects provided
by camsrfexch.atm_comp_mct does the translation between
the MCT data structures ud by the coupler and CAM's data
structures.
cam_comp
The cam_comp module provides CAM's component interfaces, i.e., the initial, run, and final methods.
camsrfexch
The camsrfexch module provides CAM's import and export state
objects.
3.2. Component Design
•!The dynamics and physics packages may u different grids, and if using the same grid may u different decompositions of that grid.
•!
•!
Chapter 4. Physics Driver
Table of Contents
4.1. Physics Drivers and Data Structures
4.1.1. Array dimensions
4.1.2. Precision of real data
4.1.3. Derived data types
