Changes to enable easily turning on CUPiD diagnostics from your CTSM case

[ekluzek]

Description of changes

The changes that are needed to turn CUPiD diagnostics from a CTSM case.

Specific notes

Contributors other than yourself, if any:
@TeaganKing @samrabin

CTSM Issues Fixed (include github issue #):

Are answers expected to change (and if so in what way)? No

Any User Interface Changes (namelist or namelist defaults changes)? Allows

RUN_POSTPROCESSING==TRUE to be used in CTSM cases

Does this create a need to change or add documentation? Did you do so? Yes
I worked on the README files, but we'll need to add to the User's Guide

Testing performed, if any:

I'm running a single test case to show the workflow. But, there are issues...

[TeaganKing]

Can we point to the documentation for running CUPiD via the CESM workflow rather than duplicating and ending up with outdated information?
I'm thinking it would also be good for me to put the land-specific 'cheat sheet' as a docs page for component-specific example of running a STANDALONE version

[TeaganKing]

Adding these in now in this PR:

CUPID_CLIMO_N_YEARS
CUPID_CLIMO_START_YEAR
CUPID_BASE_CLIMO_START_YEAR
CUPID_BASE_CLIMO_N_YEARS

[TeaganKing]

The tag will need to be updated.

[samsrabin]

Let's go through this and figure out which of these should be default settings for ALL CTSM standalone cases—i.e., not just in this usermod. (And also—which of these are already set correctly by default without us in CTSM needing to do anything.)

[samsrabin]

Maybe in cime_config/config_component.xml. But need to check that these would only apply in a standalone CTSM checkout.

[ekluzek]

I've been looking at other repositories for other things, but I see this sort of thing in config_compsets.xml for several components.

  <entries>
    <entry id="RUN_STARTDATE"> 
      <values>
        <value compset="1850_">0001-01-01</value>
      </values>
    </entry>

So it looks like that's the sort of thing that can be done. The entry is defined elsewhere, but you can set the value according to the compset as above. I think in our case we want it to be in config_component.xml, so I'll check if it can be added there.

If not we could add %CUPID as part of the CLM compset options. I don't think I like that, but it's probably something to discuss. We do have compsets that set a particular user-mod directory as part of their definition. And this would be doing that same thing here.

[ekluzek]

Point to this:

https://ncar.github.io/CUPiD/run_cesm.html

[ekluzek]

Here, point to the CUPiD documentation

[ekluzek]

We talked about this in the CTSM SE meeting this morning. I need to move onto other things, so I can't complete everything here. But, here are tasks that we do need:

• Erik will create a project board and issues for CUPiD
• CUPiD is working on v0.5.1 which will verify that CESM cases are working
• Update to that version here
• Check if Meg's key_metrics test (of atm/lnd) is expected to work without CAM
• Sam R: Will create a simple test if key_metrics nor LDF run and create a notebook
• The CUPiD test needs to create a notebook that can be checked by hand
• Adding a proper system test that validates that things worked will be later (part of the larger CUPiD project)

[TeaganKing]

A few notes:

1. Meg's notebook only reads in land files, but I have no idea whether or not it's valid without CAM turned on.
2. Just added a link to the issue ticket describing the PRs that will go into new tag
3. I feel like "The CUPiD test needs to create a notebook that can be checked by hand" may be outside the scope of this PR and theoretically should be in CUPiD.

[samsrabin]

@TeaganKing It should be in both places, I'd think. We want to make sure that whatever we have on the CTSM side does everything necessary.