Implement a basic representation of non-aerosol atmospheric state variables

[jeff-cohere]

Atmospheric temperature, pressure, density, etc are commonly used in aerosol physics. I'm wondering how we might best store them in calls to the aerosol processes.

Currently, we store prognostic aerosol state variables in Prognostics objects, and "diagnostic" state variables (interpreted various ways) in Diagnostics objects. Non-aerosol atmospheric state variables clearly don't belong in Prognostics objects because Haero doesn't "own" them and therefore doesn't evolve them. These variables could be shoehorned into Diagnostics objects, but arguably they're not "diagnostic" variables, either.

Do we need one more container for non-aerosol atmospheric state variables like pressure, temperature, relative humidity, etc? This would be passed to the run/update methods for processes as a const entity, to be used but not modified by each aerosol process.

@huiwanpnnl, @pbosler, @singhbalwinder : you've all got experience with E3SM and have expressed opinions on state variables before, so I'm tagging you on this question.

Atmospheric State Variables (incomplete--please add more!)

• Temperature at level midpoints [K]
• Pressure at level midpoints [Pa]
• Relative humidity at level midpoints [-]
• Height at level interfaces [m] (?)

[pbosler]

I think a separate state container is a good option, from the points of view of conceptual consistency and code readability. The risk that comes to mind is, does introduce redundancy with scream data and reduce efficiency?

For example, when the host model = scream, Haero's state could be defined as subviews, possibly strided, of the scream state. If the strides are big, maybe it's faster to copy subviews into local views with layout right?

If the host model is the driver, we can do anything we want. However, I'd like it to mimic our primary customer (scream) as much as possible.

Other Q: Does this imply the need for an abstract base class for haero:state that requires each host model to implement separately?

[jeff-cohere]

Excellent point about avoiding unnecessary copies of data. Before we settle on a technical solution. we need to figure out what assumptions to make about how the host model stores its data. Kokkos allows us to use unmanaged views backed by pointers to data, for example, so we might be able to impose a simple sort of "schema" on the host model that is both compatible with SCREAM and allows another host model to supply pointers to a set of known state variables. We might be able to get away with a lightweight container of pointers corresponding to those variables, for example.

Should we make a list of atmospheric state variables that we know we need?

[pbosler]

Yes, we'll need that list. Also, I think it's important to remember that we don't have to support general host models at this point. We only need to worry about scream. Maybe later we'll want to generalize so if it's not too difficult, we should build flexible data structures as a rule, but we shouldn't sacrifice scream/haero efficiency to do so.

[jeff-cohere]

It's true that we only need to consider SCREAM, and I agree we shouldn't waste too much time thinking about other host models just yet. But if it turns out to be easy for us to devise a solution that makes fewer assumptions overall, our future selves will thank us.

[huiwanpnnl]

From the "domain" perspective I would vote for having an additional container, because there is clearly a category of physical quantities that are needed for the aerosol-related calculations but are assumed to remain unchanged by the aerosol calculations. This distinction is very useful for revealing the relationships between different atmospheric process, so I would think will be useful to have that clarification reflected in the data structure, too.

[jeff-cohere]

I'm going to take a stab at a very rudimentary container for atmospheric variables, expressed in data structures that allow us to accept SCREAM fields without much fuss.