Working towards a model-independent interface for chemistry, aerosol, and atmospheric models

[mkavulich]

The Common Community Physics Package Framework (CCPP Framework) is a software interface designed to facilitate the implementation of physics parameterizations across various host models. Currently implemented within the Unified Forecast System used by NOAA, the US Navy’s developmental NEPTUNE model, and the CCPP Single-Column Model for physics research and development, CCPP has already proven itself a valuable tool for linking a common set of physics parameterizations into multiple dynamical cores.

As NWP continues to advance and physics schemes become more complex, scientists and developers are seeking to increase interoperability further by including interfaces to chemistry and aerosol models. Not only would this increase the flexibility of microphysics, radiation, and other schemes to incorporate fast coupling to prognostic aerosol and chemistry information, this would have the additional benefit of providing a model-agnostic interface between aerosol/chemistry schemes, atmospheric models, and existing physics parameterizations.

The current CCPP design philosophy has some apparent limitations when moving towards including atmospheric chemistry and aerosol schemes. A big component of CCPP’s interoperability comes from the usage of “Standard Names”, which is a compilation of standardized names for physical quantities and their exact definitions that, along with other metadata such as units and dimensions, allows for a way to pass known quantities between schemes and the host model at runtime. From the perspective of a physics scheme, it simply needs to list the standard names of quantities that it requires, and the host model provides them.

This works well for many physical quantities, but has limitations when considering some features that are prominent in (though not exclusive to) chemistry and aerosol models: lumped species (e.g., groups of distinct chemical species/isomers that are tracked in bulk by the model) and aerosol state data whose structure varies across models (e.g., dust particle bins of an arbitrary size range). Not only is a variable like “dust_bin_003” likely to be meaningless outside of the context of that specific model, even if it has a strict definition, but its ambiguity can lead to name collisions in other models that similarly bin dust or other species. Additionally, these problems with naming conventions are only part of a larger shortcoming: the various constituents of aerosol and chemistry models can be orders of magnitude more numerous than the variables considered for an average physics scheme, and so continuing with the same philosophy to pass variables individually by name will quickly become intractable. Having identified these potential shortcomings, CCPP developers are seeking ways to extend the CCPP Framework in a way that can accommodate the needs of the chemistry and aerosol community.

Steps towards a solution:
One project underway at NCAR is seeking to connect the Community Atmosphere Model (CAM) to multiple aerosol models in a model-independent way. This work introduces a set of abstract classes that define functions that can be called by physics schemes or models to retrieve data from aerosol packages in a consistent manner. These classes would then be extended by each specific model to output the requested properties, and could contain methods, derived data types, and other code necessary for interfacing between models in an abstract way. However, it should be noted that this development in CAM facilitates communication among two aerosol models (MAM and CARMA) and a single host model (CAM). It is expected that significant work would be required to make it applicable to the variety of host model/aerosol package combinations that CCPP is targeting.

As an example, there could be an abstract class for aerosol optics: this class could include methods that return various optical properties that are needed by a physics scheme, so that a physics scheme can call a function from this abstract class that would return the, say, optical depth at a certain wavelength, without having to know the specific algorithm being used to calculate those values. As another example, this class could have a method named “get_transported” that the atmospheric model could call that would return all the species that the aerosol model expects to be advected; conversely, there could be a method named “set_transported” that would return these species to the aerosol scheme.

CCPP has already started to extend the original framework to include more abstract data types with so-called “CCPP constituents”, which is a data object that can be included in a CCPP metadata file for passing arbitrary variables. But more work may be needed before a more complete class like that described above could be included.

We hope that this discussion can serve as a first step towards a two-way dialog: because the CCPP today includes aerosol-related schemes but not complex gas-phase chemistry schemes, there may be blind spots that we have yet to identify. CCPP Framework developers are especially seeking comments and contributions from other working groups that may be considering or developing ways to interface chemistry and/or aerosol schemes with atmospheric models in a model-independent way.

[ligiabernardet]

If anyone (e.g., from the aerosol community) wants to learn more about CCPP, check out this paper and the CCPP Tech Doc.
If anyone (e.g., from the physics community) wants to know more the topic of aerosol/chemistry interfaces, see this paper.