For cesm add coupling_mode to the list of attributes that can be used by component config_component.xml files

[ekluzek]

Description

For cesm add coupling_mode to the list of attributes that can be used by components config_component.xml.

Note, this happens before shell_commands is called, so you can't change coupling_mode for a case with a user or test-mod shell_commands file.

• Closes For CESM add coupling_mode to the list of attributes that can be used in components config_component.xml files #5043

Checklist

• My code follows the style guidelines of this project (black formatting)
• I have performed a self-review of my own code
• My changes generate no new warnings
• I have added tests that exercise my feature/fix and existing tests continue to pass
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding additions and changes to the documentation

[billsacks]

I've been thinking about this. Your point that you can't change this in testmods raises what I think is a broader concern, at least in my mind: I feel like it's problematic to have the defaults for xml variables depend on other xml variables. I've had the mental model: Compset sets default values of xml variables; xml settings set default values of namelist variables. The change in this PR breaks this by having some xml defaults depend on other xml defaults. Besides messing with the mental model, this also seems problematic in that it introduces an order dependence to the parsing, and raises problematic questions about what should happen if a user changes the value of COUPLING_MODE after possibly making other changes to other xml variables whose default depends on it. At the very least, I think this would require moving COUPLING_MODE to env_case.xml, but then we'd probably want a way to set it at create_newcase time, e.g., via a new flag. This is all feeling very messy.

Therefore, I think we should not bring in this change. The differentiation that you're trying to allow with this seems like it would best be done in some other way. Some ways that come to mind are: (1) differentiating on cime_model (I know that's the long-term plan); (2) adding some compset-level differentiators.

[mvertens]

@billsacks - I totally agree with the points you raise and don't think we should bring in this change as well. I think at this point if we want to have xml variables be noresm dependent we need to have noresm be parallel to cesm in cime.

[ekluzek]

OK, we decided to not do this approach. And have something possible in CDEPS. So closing.