Some arrays need accompanying properties array

[gold2718]

In order to facilitate processing by unrelated suites, arrays of constituents (e.g., a Volume Mixing Ratio (VMR) array) must be accompanied by an array of constituent properties where each element of the properties array contains the properties of the corresponding constituent.
This issue is an extension of the Proposal for Communicating Constituent Properties which contains more information on specific properties but which has been dormant for about 1.5 years.
Some properties of the constituent properties array.

• The standard name of the constituent properties array is related to the standard name of the associated constituent array. For instance, if the constituent array's standard name is volume_mixing_ratio_array, the standard name of the associated properties array would be properties_of_volume_mixing_ratio_array.
• The properties for each constituent are defined in that constituent's metadata.
• The properties for each constituent are collected into a Derived Data Type (DDT) which is created by the CCPP Framework and made available via an element of a public, protected array of objects this DDT.
• The elements of the DDT will be private with an "accessor" method for each property.

@AndrewJConley, @mattldawson, @cacraigucar, thoughts?

Some implementation thoughts:

• I am thinking of implementing the DDT in its own module or perhaps in ccpp_kinds.F90 (since it is a kind).
• A particular constituent properties array will probably be written either to its own module or to the suite CAP file. It will be initialized at the top of the suite's initialization subroutine (there are still compiler issues with initializing DDT arrays as module data). An advantage of having it in its own module is avoiding possible circular dependency issues since the array will be defined in one suite but will also used by a different suite and the host model.
• The accessor functions could be used directly but will also probably be accessible as host cap functions (which take a standard name plus an index) to ease use from host models.
• Direct accessor use by physics schemes will be enabled by having the properties array as an input (via the standard name above).

[mattldawson]

Hi @gold2718 - looks great to me! I think this will help avoid the Sisyphean task of standardizing names of lumped organic species across chemical mechanisms, emissions schemes, photolysis modules, etc. and allow schemes to treat species based on their properties (as opposed to their names) to the extent this is possible.

Having these derived types in separate modules sounds like a reasonable approach.

One very minor thing: when it comes time to name these properties for chemical species could we use something along the lines of chemical_species_volume_mixing_ratio and chemical_species_properties or gas_volume_mixing_ratio and gas_properties? - only because these are properties of the species and not necessarily their volume mixing ratios.

[gold2718]

Note that this issue is related to, and may subsume #276.

[gold2718]

@mattldawson, Thinking about this a bit, I think we could have one array called chemical_species_array which could have some species which are VMR and some which are MMR (or something else such as number concentration). The distinction would be made via the standard name (e.g., ozone_vmr vs. ozone_mmr). The same would be true of a gas_species_array.
Another question would be if we want to have a water_species_array which could be useful in computing wet to dry to wet conversions (answering the question of how many water species to include).
Thoughts? @grantfirl, @climbfuji, @AndrewJConley, @cacraigucar?

[mattldawson]

Hi @gold2718, So just to make sure I'm understanding, there would be something like:

  !> for explicitly named species...
  real :: ozone_vmr(n_col, n_cell)
  type(chem_prop_t) :: ozone_properties
  real :: no2_mmr(n_col, n_cell)
  type(chem_prop_t) :: no2_properties

  !> ... and for ambiguously named species...
  real :: gas_species_vmr(n_col, n_cell, n_species) ! (or mmr or #/cc or whatever is decided)
  type(chem_prop_t) :: gas_species_properties(n_species)

Is this sort of the idea?

[AndrewJConley]

For the gas-phase chemicals, the chemists work with the number density of all of the species. Number density has a lower dependence on the context of the host model. I.e., to what thing is the ratio constructed in an arbitrary host model? Wet ratio? Dry ratio? Wet ratio excluding condensed material?
Of course, this is perspective is particular to the collection of chemical models being developed for NCAR/ACOM

[AndrewJConley]

As far as wet/dry/mass/volume conversions go, those are all scheme/model-specific decisions, as the denominator depends upon the scheme’s assumptions as to what the denominator is.

[gold2718]

@mattldawson, You can have an explicitly-named species as an element of an array.

[ q ]
  standard_name = gas_species_array
  type = real |   kind = kind_phys
  units = kg/kg moist or dry air depending on type
  dimensions = (horizontal_dimension, vertical_layer_dimension, number_of_chemical_species)
[ q(:,:,index_of_ozone_vmr) ]
  standard_name = ozone_vmr
  type = real |   kind = kind_phys
  units = ppmv # Or whatever units we want here
  dimensions = (horizontal_dimension, vertical_layer_dimension)
[ q(:,:,index_of_co2_mmr) ]
  standard_name = co2_mmr
  type = real |   kind = kind_phys
  units = kg kg-1
  dimensions = (horizontal_dimension, vertical_layer_dimension)

The issue here is what is the type of all the other elements of q which are not listed explicitly? We could require every species to be "named" even if a lot of the standard names are things like standard_name_101_vmr or standard_name_923423829_mmr.

[gold2718]

@AndrewJConley, that's why I think the water_species_array is an interesting concept. Whoever controls that array controls the definition of 'wet' for the run.

[fvitt]

I agree with @AndrewJConley. Things would be simpler if q is the number density of all the tracers rather than a ratio. If a scheme wants a mixing ratio it can derive it from the number densities, defined however they like.

[fvitt]

It seems to me like we need a collection of constituent objects. Each object be queried for properties or attributes and state (concentration).

[gold2718]

Suggestion from @climbfuji:
In addition to chemical_species_array, gas_species_array and water_species_array. we could define arrays such as advected_species_array and other special-purpose arrays which would be known to the framework. This would enable, for example, the host model to specify the advected_species_array in its 'host' metadata and the framework would provide or update that array on each call to a CCPP physics group.

[climbfuji]

Suggestion from @climbfuji:
In addition to chemical_species_array, gas_species_array and water_species_array. we could define arrays such as advected_species_array and other special-purpose arrays which would be known to the framework. This would enable, for example, the host model to specify the advected_species_array in its 'host' metadata and the framework would provide or update that array on each call to a CCPP physics group.

I followed up with GFDL on this question, and they already have that capability in their dycore. That is, two separate arrays of tracers, q and qdiag (the latter not advected). This capability is just not used in the UFS. So all it takes is to make the connection of those arrays with the CCPP standard names.