Duplication problem in user_mods

[adrifoster]

Right now we have duplication of user_mods for NEON for use with big leaf CLM and FATES. Because of the way we need to include various commands and parameters for all NEON sites and others for specific NEON sites, when we added user_mods to run CTSM-FATES we just duplicated all the folders. This means that if we update any site in the big-leaf set of folders, we also have to update it in the FATES set of folders, and vice versa.

We should come up with a way to remove this duplication without it being too convoluted and difficult for a naive user/developer to understand.

[ekluzek]

One idea to handle this was discussed here:

https://github.com/ESCOMP/CTSM/pull/1932#pullrequestreview-1244307112

We also wondered if we should make changes in cime to support this kind of situation.

[billsacks]

We'll revisit this after the PRISM-related user mods come in from @TeaganKing (#1954 ) - at which point we'll look at whether we can come up with a solution that might clean up both.

[ekluzek]

@wwieder has the suggestion to use shell_commands to contain both user-mods for BGC, SP, and FATES in one place.

https://github.com/ESCOMP/CTSM/issues/2037#issuecomment-1603102654

Also #2028 helps with this as well.

[ekluzek]

When I look at the difference between the FATES NEON usermods and non-FATES the difference is the surface dataset (which I suggest we resolve with #2028) and the history fields. Since, the history fields depends on specifics about the compset it probably would make sense to do it this way.

There could be a structure like:

if [[ "BGC" ]]; then
else if [[ "SP" ]]; then
else if [[ "FATES-SP" ]]; then
else if [[ "full FATES" ]]; then
fi

That then sets what the hist_fincl2 should look like for each of the different major compset types.

[wwieder]

This makes sense, but I think it requires having a FATES sp compset, which we currently don't have.

In previous discussions I seem to remember advocates for a single FATES compset and requiring users to use nl changes to turn on/off the FATES configuration they wanted (e.g. greater user responsibility). My memory here is fuzzy, and it's also a topic I'd assume we discuss next week with our broader compset, namelist, usermod conversation.

[ekluzek]

@wwieder we do actually have a FATES-S Pcompset. There's two for both GSWP3 and CRUNCEP forcing. Here's the GSWP one..

  <compset>
    <alias>I2000Clm51FatesSpRsGs</alias>
    <lname>2000_DATM%GSWP3v1_CLM51%FATES-SP_SICE_SOCN_SROF_SGLC_SWAV</lname>
  </compset>

But, yes you are spot on that we have those three methods of setting things: compset, namelist, user-mod and we should have a philosophy that helps us figure out when we use one over the other (note I'd also add XML-variables to that list). I have some ideas about that, but it's also something for us to decide as a group. I think we still need all four, but we can also decide which ones we use more often, and for what types of things.

[wwieder]

Oh, do we have a single point fates SP compset? Maybe that's what we need?

[ekluzek]

Ahhh, yes we don't have that. Although technically you could use a compset long-name.