Compset matches in config_component_cesm.xml should be made more general

[billsacks]

Background

Moving ESMCI/cime#119 to here; I am copying the 10-year-old comments verbatim - not updating paths, etc. This depends on ESMCI/cime#3816.

Comment 1 (March 25, 2016)

Many of the compset matches in driver_cpl/cime_config/config_component.xml seem fragile, especially if we want this same file to work for a variety of active components. Examples are the various NCPL settings and CPL_SEQ_OPTION.

It feels like there references here to specific component names should mostly be eliminated (although it looks like they may be needed in some cases - e.g., to distinguish between the desired coupling frequency of POP vs. MPAS). I'm not sure what would be the best way to solve this problem, but one idea is to have variables like LND_COMP_TYPE saying whether (for example) the land model is active, data, stub or coupler_test - and same for OCN, ATM, GLC, ICE, etc. Then buggy(?) rules like this (for OCN_NCPL):

  <value compset="_DATM.*_CLM4.*_SICE.*_SOCN">1</value>

could be written as

ATM_COMP_TYPE="data" LND_COMP_TYPE="active" ICE_COMP_TYPE="stub" OCN_COMP_TYPE="stub"

Comment 2 (March 25, 2016)

Things like this also concern me (for CCSM_BGC):

      <value compset="HIST.*_DATM%(QIA|CRU)">CO2A</value>
      <value compset="RCP.*_DATM%(QIA|CRU)" >CO2A</value>

What if someone introduces a new DATM mode? It's so easy to miss the fact that you need to update the driver's config_component for things like this.

I often wish that we didn't have the ability to have regular expression matches against compset at all in these xml files, but instead required that components set various pieces of metadata that could be queried for these purposes.

Comment 3 (March 25, 2016)

In talking this through with Mariana, we feel that there are a few things going on here that should be addressed at some point. This isn't critical, but will be important to address if we want the driver to be more component-independent:

• We should get rid of regular expression matching in the xml files, since this is error-prone. Instead, the compset long name should be split into pieces, and then you can match against those individual pieces (e.g., ATM_NAME, ATM_OPTIONS, etc.).
• We should introduce general variables like ATM_TYPE, LND_TYPE, etc., which would have the possible values active, stub, data, coupler_test. Where possible, we should match on those general types. If (for example) you want to do some setting when running with active land, the current workaround is to have a regex match like ^(DLND|SLND|XLND), but that is error-prone. (I'm not at all confident that I just wrote that regex correctly.)
• For examples like CCSM_BGC, we could also match against a (new) variable that tells us that we're doing a transient run. Again, the principle should be: match against higher-level abstractions, not directly against the compset name: Matching against the compset name is problematic as we rework compset names, add new options, etc.
• For driver settings that truly are tied in with a specific set of active models (as is the case for the NCPL settings), these settings should be moved to cime_config/cesm. These can match against things like ATM_NAME, rather than matching against the compset with a regex. However, these model-specific settings should be kept to the bare minimum.
• We should really strive to have rules mean what they say and say what they mean. As an example, if a rule is meant to apply when running with a data runoff model, then it should be written that way -- not matching against "DATM.*POP" (because everyone knows that, if you're running with DATM and POP then you're using DROF, too, right?).

Comment 4 (March 29, 2016)

There are similar compset matches in config_pes.xml and config_grids.xml - and maybe elsewhere - which should also be handled similarly.

Comment 5 (June 12, 2017)

For some more examples and thinking around this issue, see ESMCI/cime#1522 (comment) and ESMCI/cime#1522 (comment) and some follow-on comments in that issue

Comment 6 (October 22, 2018)

Yet again, the fragile regular expression matches on compset are causing problems and slowing us down (for example, see the change I needed to make in ESCOMP/CESM_CICE5@ac908ac)