Create abstract aerosol classes and stub aerosol model

[mattldawson]

Create an initial set of abstract aerosol classes based on those used to track aerosol parameters and state information in CAM. This initial version should just allow for the initialization of an aerosol model, and the ability for it to provide aerosol optical properties for a given state.

Also, implement a stub aerosol class that extends the abstract classes and returns values of 0 for all aerosol optical properties.

[gold2718]

How are these abstract classes related to the ones currently in use in CAM?
E.g., are they replacements? Enhancements? Something else?

[gold2718]

The current classes in CAM provide an interface to allow an aerosol model to prepare quantities for advection and to process the results. I feel that we need more similar interfaces for other model processes. For example:

• chemistry: An aerosol model would use these interfaces to convert its internal state into species required by chemistry and to process the changes after chemical processes are run. Do we need different interfaces for gas-phase chemistry and aqueous-phase chemistry?
• cloud microphysics: This is similar to chemistry in that the aerosol model should provide interfaces that provide microphysics with information such as provided today by rad_constituents and ndrop.
• radiation: A radiation scheme requires information from the aerosol model, e.g., extinction coefficients. The aerosol_optics type family seems intended to provide this information but I would like to understand its relationship to the aerosol properties and state objects.

[gold2718]

Is it a design goal to allow the creation of multiple aerosol objects? I can imagine that a model or physics package might want to run different aerosol models in parallel. For instance, one model could be used in a prognostic capacity with a second used as a diagnostic for comparison. The model should treat the aerosol object as a persistent object that carries an evolving state throughout an experiment.

[gold2718]

The current aerosol objects provide information about themselves, however, I feel that information is too general. For instance, in determining the what optical properties are available, CAM relies on an optics type of 'modal' to retrieve refractive aerosol optics information (aerosol_optics_cam.F90). Instead, could the object be a bit more reflective? Something like replacing:

          call aeroprops%optics_params(list_idx, ibin, opticstype=opticstype)

          select case (trim(opticstype))
          case('modal') ! refractive method
             aero_optics=>refractive_aerosol_optics(aeroprops, aerostate, list_idx, ibin, &
                                                    ncol, pver, nswbands, nlwbands, crefwsw, crefwlw)
          case default
             call endrun(prefix//'optics method not recognized')
          end select

with

          aeroprops%aerosol_optics(aeroprops, aerostate, list_idx, ibin, &
                                                    ncol, pver, nswbands, nlwbands, crefwsw, crefwlw)

While this is not currently possible due to module dependencies, reorienting responsibilities between classes could enable this kind of interface streamlining. Another possibility is introducing an 'aerosol_model' class which in the singular interface class. Internally, it would hold a singleton of the appropriate properties class. With a bit of adjustment, the aerosol_state object could fulfill this purpose. The call could then be:

          aerostate%aerosol_optics(list_idx, ibin, ncol, pver, &
                                                    nswbands, nlwbands, crefwsw, crefwlw)

[mattldawson]

How are these abstract classes related to the ones currently in use in CAM? E.g., are they replacements? Enhancements? Something else?

I guess they could be considered replacements or enhancements. They are intended to allow us to do the second phase of aerosol refactoring, which removes the CAM dependencies from the aerosol model code.

[mattldawson]

The current classes in CAM provide an interface to allow an aerosol model to prepare quantities for advection and to process the results. I feel that we need more similar interfaces for other model processes. For example:

• chemistry: An aerosol model would use these interfaces to convert its internal state into species required by chemistry and to process the changes after chemical processes are run. Do we need different interfaces for gas-phase chemistry and aqueous-phase chemistry?
• cloud microphysics: This is similar to chemistry in that the aerosol model should provide interfaces that provide microphysics with information such as provided today by rad_constituents and ndrop.
• radiation: A radiation scheme requires information from the aerosol model, e.g., extinction coefficients. The aerosol_optics type family seems intended to provide this information but I would like to understand its relationship to the aerosol properties and state objects.

We will be creating additional issues for these types of interactions, but in the spirit of incremental development, we created this issue to just put in place an initial version of the aerosol classes that can be used in CAM-SIMA, starting with just the radiation interface.