New naming convention for development runs

[cecilehannay]

There has been talks to change the naming convention for the casenames. So far, we have been following (more or less) the CESM2 naming conventions

The convention:
<compset char>.<code base>.<compset shortname>.<res shortname>[.opt_desc_string].<nnn>[opt_char]

Details:

- <compset char> is a single character, the first letter of the compset, lower case
- <code base> is "e20" for cesm2.0, "e10" for cesm1.0, "c40" for ccsm4.0, "c35" for ccsm3.5
- <compset shortname> is the compset shortname recognized by create_newcase
- <res shortname> is the resolution shortname recognized by create_newcase
- [.opt_desc_string] is an OPTIONAL descriptive string, the only constraint is that it must not contain a "." (as this is reserved for delineating and parsing components of the case name). While this string is largely unconstrained, CSEG strongly encourages users to either create a very short string (eg. eight characters or less) or avoid using it altogether.
- <nnn> is a 3 digit number, the smallest number that results in a unique case name
- [opt_char] is an OPTIONAL single lower-case letter {a,b,...,z}, normally not used, but is allowed to denote a group of cases that are very closely related. Those cases would then have identical case names except for this single character suffix.

For instance, the latest control run was named:
f.e21.FWscHIST.ne30_L48_BL10_cam6_3_046_control.hf.001
(Note that the 'hf' was something to differentiate the runs with high frequency output. But as they all have this will drop that)

Following strictly the CESM2 convention, the case name should be something like:
f.cam6_3_046.FWscHIST.ne30pg3_ne30pg3_mg17_control_L48_BL10.001
or maybe:
f.cam6_3_046.FWscHIST.ne30pg3_ne30pg3_mg17_control_L58.001

It would be great to end up with shorter names. This discussion is for people who have an opinion on that.

[cecilehannay]

@dan800 suggested:

I think just going with (b/f).CAM7LXX.vNN.YY (XX levels, NN version number, YY=HIST or 1850 or 4XCO2...) and having a table on github that details the various version number changes.

[cecilehannay]

Comments about Dan's suggestion.

• This is a good starting point. Much shorter names.
• However it doesn't contain any info about the horizontal res or dycore. And not much about compset. Maybe it is fine but I think it should be discussed.
• During CESM2 development, we had a long table with all the 300 simulations CESM2 simulations just differentiated by number 001, 002, ..., 297.
  And some people didn't like it and wanted to do it differently (I personally liked the long table but I think it was because I was doing the simulations. But other didn't like that naming and the long table. For instance, I think @[email protected] didn't like the long table)

Thoughts? Ideas?

[swrneale]

@cecilehannay Yes I don't like a long list. In git you can search run issues, add as much meta data description and comments as you like. And no endless scrolling! wrt to naming convections we have to be be careful as we will be running coupled simulations at some point and would either revert back to the existing naming convection or convince all the other components to use ours. I think getting rid of the tag name, simplifying to 'L58/L93' and having no, or a coded description (lie 'control'/ctl) should make it short enough. All this info. that is removed should appear in the issues like it already does.

[adamrher]

I think we should probably retain some reference to the cam tag, since the code base is constantly moving under us as we bring in all the CAM7dev PRs. Instead of cam6_3_41, we could do c6.3.41 or something like that.

[cecilehannay]

For instance:
f.c6_3_46.FHIST.ne30pg3_L58.001
or
f.c6_3_46.FHIST.ne30_L58.001

This would follow more or less CESM2 conventions but with shorter names.