Configuration of CAM
CAM is the atmospheric model that is part of the fully-coupled Community Earth System Model (CESM). CAM can be run in standalone mode or in coupled mode as part of CESM. CAM is considerably flexible in its configuration process because it is designed to support a number of different scientific scenarios. Because of this, configuration of CAM is a complex process (especially behind the scenes). Roughly speaking, to run CAM in standalone mode, the user will execute the “configure” script and provide a number of command line parameters that describe his or her particular configuration choices (e.g., use the finite volume dynamical core and the trop_mam7 chemistry package, etc.). Most configuration options have default values, so the user must only supply those parameters that differ from the default. Only certain source code folders will be included in the final compilation based on the user’s choices.
One primary function of the CAM configure script is to enforce constraints among the configuration options. For example, using offline dynamics requires the finite volume dynamical core, and single column CAM (SCAM) can only be run in serial (non-parallel) mode. There are a large number of similar constraints embedded in the configure script. The configurable nature of CAM makes it more akin to a Software Product Line (SPL) than a single software application. In other words, the CAM codebase can be used to create a large number of related software applications that vary in different ways.
Feature model diagrams offer a convenient and simple notation for documenting commonality and variation points in SPLs. (See here for an example feature diagram.) Feature diagrams also allow you to depict simple constraints among the features. This should be helpful, at least, for visualizing the variation points (configuration options) of CAM and constraints among the different configuration options.
In its current manifestation, I have selected those configuration options that deal primarily with scientific and numerical requirements and coupling. I have left off some of the more technical options (e.g., where to save the executable, the location of the MPI library) for space considerations. Nonetheless, the diagram is very large right now (and almost unmanageable). I’m on the lookout for a better way to display the diagram (collapsible features, for example, would be very handy). For now, here it is as a PDF. You’ll have to zoom in to see the details.
In addition to a mechanism for visualizing configuration possibilities and representing them declaratively, there are other potential advantages to the feature model, especially if it is formalized into a knowledge base. There has been much work on automated analysis of feature models that may be useful in the context of configuring CAM.
- Automated reasoners can determine if a particular product (configuration) is valid based on the constraints in the feature model. The reasoner could validate user configurations of CAM.
- Partial configurations can also be checked for validity. This allows for an incremental configuration process that guides the user in selecting compatible options.
- Explanations can be given about why a particular configuration is invalid.
- Recommendations can be given for ways to correct invalid configurations.
- Canned configurations (e.g., those that are scientifically pre-validated) can be stored for later retrieval.
- Custom configurations can be stored as provenance metadata.
- Configuration shell scripts could be generated automatically from the feature model (i.e., taking the place of the reasoner).