Draft aerosol classes

[mattldawson]

Adds an initial implementation of the abstract aerosol classes from CAM along with a stub aerosol model.

closes #205

I'll leave this in draft while we iterate on the design. This makes a few modifications to the CAM aerosol classes' virtual functions including:

• returning optical properties for all grid cells and wavelength bins
• having the aerosol model state own its own data, as opposed to it being managed externally
• specifying a wavelength grid for optical properties to be returned on

This design should also support concurrent use of multiple aerosol models and/or multiple state objects for a single aerosol model instance.

The best place to start reviewing this is probably in test/musica/aerosol/mock_host.F90, which shows how a simple host model might use the aerosol classes with a radiation package.

@gold2718 - let me know if you think this structure will work for your use case. Feel free to request changes or submit PRs to my dev branch. We could also set up a meeting to discuss needs in more detail.

Is this an answer-changing PR? If so, is it a new physics package, algorithm change, tuning change, etc?
no

If yes to the above question, describe how this code was validated with the new/modified features:
n/a

[peverwhee]

Thanks @mattldawson! I'm curious about how the aerosol_model_t and aerosol_state_t objects relate/will relate to the objects that Francis has been working on in CAM?

I guess I expected that the abstract classes would be the same as those in CAM (e.g. aerosol_state_mod.F90 and aerosol_properties_mod.F90)

But I also have an admittedly limited understanding of how this all works and will work in the future.

[mattldawson]

Thanks @mattldawson! I'm curious about how the aerosol_model_t and aerosol_state_t objects relate/will relate to the objects that Francis has been working on in CAM?

I guess I expected that the abstract classes would be the same as those in CAM (e.g. aerosol_state_mod.F90 and aerosol_properties_mod.F90)

But I also have an admittedly limited understanding of how this all works and will work in the future.

The aerosol_model_t corresponds to the one in aerosol_properties_mod and the aerosol_state_t class to the one in aerosol_state_mod.

The reason we need new classes in this repo is that the current implementations of the aerosol classes (for MAM and CARMA) include CAM dependencies in the aerosol functions (state, pbuf, rad_constituents, etc.). In order to get that code to build in CAM-SIMA we would need to port ALL of the aerosol functions at once (including the functions needed for radiation, cloud activation, ice nucleation, deposition, etc.).

So, instead, we can create these two new stub classes and gradually move the aerosol functions into them one at a time (removing them from the existing modules as we remove the CAM dependencies), starting with just the radiation interface. Does this make sense?

[peverwhee]

Thanks @mattldawson! I'm curious about how the aerosol_model_t and aerosol_state_t objects relate/will relate to the objects that Francis has been working on in CAM?
I guess I expected that the abstract classes would be the same as those in CAM (e.g. aerosol_state_mod.F90 and aerosol_properties_mod.F90)
But I also have an admittedly limited understanding of how this all works and will work in the future.

The aerosol_model_t corresponds to the one in aerosol_properties_mod and the aerosol_state_t class to the one in aerosol_state_mod.

The reason we need new classes in this repo is that the current implementations of the aerosol classes (for MAM and CARMA) include CAM dependencies in the aerosol functions (state, pbuf, rad_constituents, etc.). In order to get that code to build in CAM-SIMA we would need to port ALL of the aerosol functions at once (including the functions needed for radiation, cloud activation, ice nucleation, deposition, etc.).

So, instead, we can create these two new stub classes and gradually move the aerosol functions into them one at a time (removing them from the existing modules as we remove the CAM dependencies), starting with just the radiation interface. Does this make sense?

Thank for elaborating. I definitely understand building things up piece by piece, but what I'm still a bit confused by is why the procedures/classes have different names. Won't this make incorporating the work that Francis has already done more complicated?

[mattldawson]

Thanks @mattldawson! I'm curious about how the aerosol_model_t and aerosol_state_t objects relate/will relate to the objects that Francis has been working on in CAM?
I guess I expected that the abstract classes would be the same as those in CAM (e.g. aerosol_state_mod.F90 and aerosol_properties_mod.F90)
But I also have an admittedly limited understanding of how this all works and will work in the future.

The aerosol_model_t corresponds to the one in aerosol_properties_mod and the aerosol_state_t class to the one in aerosol_state_mod.
The reason we need new classes in this repo is that the current implementations of the aerosol classes (for MAM and CARMA) include CAM dependencies in the aerosol functions (state, pbuf, rad_constituents, etc.). In order to get that code to build in CAM-SIMA we would need to port ALL of the aerosol functions at once (including the functions needed for radiation, cloud activation, ice nucleation, deposition, etc.).
So, instead, we can create these two new stub classes and gradually move the aerosol functions into them one at a time (removing them from the existing modules as we remove the CAM dependencies), starting with just the radiation interface. Does this make sense?

Thank for elaborating. I definitely understand building things up piece by piece, but what I'm still a bit confused by is why the procedures/classes have different names. Won't this make incorporating the work that Francis has already done more complicated?

We could definitely give them similar names (I just went with model instead of properties because I thought it would make the simultaneous use of different aerosol models like @gold2718 suggested a little clearer). But, the module names will have to be (at least slightly) different because they will be being used simultaneously until all the aerosol functionality is finished in CAM-SIMA.

I don't expect that renaming of functions or classes will make incorporating Francis's work that difficult. There's often only one or at most a few functions involved in the interface to any particular physics scheme. Removing the CAM dependencies from the code will also very likely mean changing some of the function arguments, so there will probably always be some changes to the function signatures.