Rework logic for CPL_ALBAV xml variable
Moving this over from https://github.com/ESMCI/cime/issues/120
Here were the comments from there (from 2016), but I think it's still relevant:
This is related to issue ESMCI/cime#119: The logic for CPL_ALBAV in driver_cpl/cime_config/config_component.xml currently looks like this:
<entry id="CPL_ALBAV">
<type>logical</type>
<valid_values>true,false</valid_values>
<default_value>false</default_value>
<values>
<value compset="DATM.+POP">true</value>
<value compset="DATM.+DOCN%IAF">true</value>
</values>
<group>run_component_cpl</group>
<file>env_run.xml</file>
<desc>
Only used for compsets with DATM and POP (currently C and G):
If true, compute albedos to work with daily avg SW down
If false (default), albedos are computed with the assumption that downward
solar radiation from the atm component has a diurnal cycle and zenith-angle
dependence. This is normally the case when using an active atm component
If true, albedos are computed with the assumption that downward
solar radiation from the atm component is a daily average quantity and
does not have a zenith-angle dependence. This is often the case when
using a data atm component. Only used for compsets with DATM and POP (currently C and G)
</desc>
</entry>
Really, it seems that this shouldn't depend on the compset, but rather should depend on some property of the atmospheric forcing. So this should be set by the atmosphere component, either at build-namelist time or at runtime. It seems possible to set this in datm's config_component.xml. But it seems like, to really make this robust and avoid duplicated logic (which is likely to become incorrect over time), it might need to be set at runtime, by the atmosphere component setting some flag (e.g., in infodata??).
This is an issue for the new J compset that Jeremy Fyke and I are putting together: all active except a data atmosphere. We haven't determined what datm forcing to use for this compset, and will likely iterate on this a bit. It appears that CPL_ALBAV should have a different value if we're using (e.g.) CORE forcing (so datm acts like it does in C & G compsets) or CRU forcing (so datm acts like it does in I compsets).
#594 illustrates why this is important - to make it more likely that this gets set correctly for each ocean forcing. Setting this in datm isn't totally straightforward, because it's information needed in CMEPS, but it could be done via drv_flds_in similarly to how we currently set "atm_ozone_frequency" (which is a variable that serves a conceptually similar purpose; that one is always the same right now for datm forcing, but can vary for CAM forcing).
In the short-term, @mvertens is working on some changes that at least improve the logic of this within CMEPS.