EAMxx integration: MAM4AerosolMicrophysics AtmosphereProcess

[jeff-cohere]

This issue tracks the development of an AtmosphereProcess subclass that evolves aerosols using mam4xx's parameterizations. We may end up having more than one of these AtmosphereProcess classes related to aerosols.

What's written here is fairly technical, since I'm using it to gather and organize my thoughts on this process. If you're interested in understanding what something means, or if you see an issue with something here, please don't hesitate to comment.

Prior Art

• P3 (hpp, cpp)
• SHOC (hpp, cpp)

Notes and Questions

• Do we need to use EKAT's WorkspaceManager to get memory for column variables? So far, I don't think so. So far, most operations can be performed at a single vertical level, which means our parameterizations probably don't have to create temporary ColumnViews. This is a good thing worth defending a bit, because managing memory (on GPUs specifically, but also in general) is tricky.
• Do we need to store any local variables using the Buffer and AtmBufferManager? Answering this question probably requires looking at how aerosol data is stored in and extracted from the physics buffer in E3SM.
• Do we need to implement set_grids? Yes. Because each of our aerosol prognostic variables is stored as a tracer in SCREAM's tracers field group (see how SHOC extracts tracer info here), we need to keep track of the physics grid.
• How can we handle the conversion from wet to dry mixing ratios? SCREAM uses "moist" air mass, etc, whereas MAM4 uses dry air mass. It turns out that SHOC also uses dry air mass, so we can look at how SHOC performs this conversion. #40 also touches on this topic.
• Should we defineMAM4Preprocess and MAM4Postprocess types as is done in e.g. SHOC? This seems like a good idea. SHOC uses these types to perform the conversion between moist and dry mixing ratios, and it's nice to keep that calculation separate from others.
• How do we select only the specific aerosol tracers from the qtracers array? SHOC operates on all tracers (which, by the way, may or may not be what we want for the treatment of vertical mixing for aerosols[!]). MAM4, on the other hand, only cares about aerosol number and mass mixing ratios.

Anatomy of a Time Step

Someday, this will be a hot topic! For now, we'll do staged development to convince ourselves that we know what we're doing. These steps are only sketched here--I'll probably track them each in their own separate issue.

Stage 1: A do-nothing atmosphere process

We start by implementing a very basic AtmosphereProcess subclass that extracts aerosol and related gas tracer quantities from the tracers field on the physics grid, does nothing to them, and places them unmodified back into the tracers field.

We can make use of the mam4::AeroConfig and mam4::Prognostics types for this task, extracting fields to views within a set of columns, and then copying the values back into place.

Stage 2: Add nucleation

As a foray into aerosol dynamics, we devise a test problem in which we seed the atmosphere with localized sulphuric acid gas, let it nucleate into sulphate aerosol (to be placed in the Aitken mode), and watch the nucleation process deplete the gas. It would probably be interesting to introduce a velocity field that moves things around in a quantifiable (and verifiable, if possible) manner.

To execute this test problem, we add the nucleation process to our implementation, initializing it in the appropriate place and running it within the run_impl method of the MAM4Aerosols class. We can integrate the tendencies computed for the aerosols and gases directly into the aerosol prognostics for each column. Those values then get copied back into the tracers field using code written for Stage 1.

Stage 3: ???

[jeff-cohere]

Changed the name of this issue to reflect our near-term goal: MAM4 aerosol microphysics

[jeff-cohere]

This issue has been superseded by #169