Move settings from use_cases to namelist_defaults

[billsacks]

Let me preface this by saying that I've never fully grasped the motivation for having use_cases (bld/namelist_files/use_cases), so I may be missing something here. But that said:

I'd like to see use cases removed and replaced with their analogous settings in the namelist_defaults xml file. My rationale is: even though use cases make sense for what they do, it's confusing and error-prone to have this additional mechanism that is just used for a handful of namelist variables. Even if the organization of namelist_defaults is less ideal for these variables, I think the upside of consistency and only needing to look in one place outweighs this downside.

I think this is actually a bigger problem because of how few variables are set via use cases. I'd say that 99% (or more) of the time when I'm messing with namelist defaults, I don't need to think about these use cases... which means that the 1% that I do need to look there, I forget to do so.

Definition of done:

• [ ] Simplify the use-cases to remove unneeded variables
• [ ] Have use-cases only have sim_year, sim_year_range and rcp in the use cases, and move all of the other variables that are currently in use cases to namelist_defaults (with dependence on those three).
• [ ] Move use-cases as a setting in namelist definition, and move the settings into the namelist_default file using use_case as the attribute that distinguishes the different options
• [ ] Set sim_year, sim_year_range and rcp in a different way (e.g., via their own xml variables)?

[ekluzek]

I'm certainly willing to talk about this. It's possible the main motivation is really all around the simulation year, which we enter anyway. So it's possible all these things could be handled by looking at the sim_year or looking at if it's transient or not. It's also something where we adopted something that CAM was (and is) doing. So you could argue about the need for it in CTSM.

The principle is that the use-cases put together a set of defaults that should be used for a particular standard case. And as such the list of namelist variables is somewhat random. And the mechanism allows any list of namelist variables to be included in the set, which makes it a convenient way to package things together. The only way to do that kind of packaging without use-cases is to have an attribute that controls it.

This is something that we've had in place for a while, so I'd like to also hear from users about this. Almost all COMPSETS that you choose, are going to pick a use-case. So users are using this even if they don't realize it.

[ekluzek]

I'm going to add another wrinkle to this issue that makes use_cases difficult. The only valid attributes that can be used in the use_case files are the ones that it sets up. I was noticing it wasn't paying attention to an attribute, but that is the reason why. So that's causes a bit of an unexpected behavior. This could possibly, be it's own issue, but I'm just going to put it here for now.

[billsacks]

@ekluzek suggests, as a first step, we keep only sim_year, sim_year_range and rcp in the use cases, and move all of the other variables that are currently in use cases to namelist_defaults (with dependence on those three).

Then a second step could be setting sim_year, sim_year_range and rcp in a different way (e.g., via their own xml variables).

[ekluzek]

This idea comes up again in #1929

[ekluzek]

In #2501 enough simplification was done that I could see us finishing this off. The approach could be to keep the use-case attributes, but everything would be in the namelist_defaults_ctsm.xml rather than in separate files in the use-case subdirectory. And the problem in #2492 was largely a result of this issue.