Linkbcs Standalone Script

[sshakoor1]

(This is the same as #820, just renamed as per request of @rtodling #820 (review))

The purpose of this PR is create a new linkbcs that is no longer a template file detemplated by gcm_setup, but rather a standalone python script ran via a config yaml. This new script should essentially be zero-diff from the old one.

To run, use $INSTALL_DIR/bin/linkbcs.py --config <USER_CONFIG>.yaml --timestamp <YYYY>-<MM>-<DD>T<HH>:<MM>:<SS> from inside the directory you want your symlinks to be created.

Here is a skeleton of what the config yaml should look like, along with valid options for each key:

experiment_type: #GCM or ADAS
agcm_grid: #c12, c24, c48, c90, etc.
land_version: #icarus, icarus-NLv3, v12, v14
ocean_model: #data, mom6, MIT
ogcm_grid: #reynolds, merra-2, ostia, cubed_sphere_ostia, cubed_sphere_ostia_r21c
seaice_model: #cice4 or cice6 (this entry is only required for coupled ocean)
precip_correction: #True or False 
catchcn: #True or False
pchem_species: #ops, cmip, s2s, merra-2
dual_ocean: #True or False
boundary_dir: /path/to/your/boundary_dir
install_dir: /path/to/your/install_dir

SOME NOTES:

• these entries are case sensitive at the moment.
• The install_dir should point to the directory your build of GEOS is installed in. For most people this will simply be .../<user_dir>/GEOSgcm/install/
• Right now only the year matters in the timestamp, but you still need to put entries for the time/month/day (they could all be zero).

[rtodling]

have now tested this quite extensively. I run first a regular one-cycle experiment at a random date and got zero diff w/ my control. Then, just for the hack of it, I move the experiment to the edge of a year and cycled for a number of cycles from there. In the end I still got zero-diff.

So: I am happy with/ this - very happy.

Thank you so much.

This has been tested w/ what is basically v11.7.3 (in ADAS mode).

[mathomp4]

Confirmed works at NAS with c24 and c12-MOM6

[gmao-rreichle]

Here's an attempt to further answer @mathomp4's comment on #902:

@gmao-rreichle There is a whole bunch of comments above that about picking the right PRECIP_FILE. Do you know if any of that is even still accurate?

I ask only because @sshakoor1 and myself were a bit confused by the precip correction stuff when he was working on his linkbcs.py script (see #823). In his bcs_catalog.yaml for this he has:

precip_correction:
  r21c: /discover/nobackup/projects/gmao/share/gmao_ops/fvInput/merra_land/precip_CPCUexcludeAfrica-CMAP_corrected_MERRA/GEOSdas-2_1_4
  merra-2: /discover/nobackup/projects/gmao/share/gmao_ops/fvInput/merra_land/precip_CPCUexcludeAfrica-CMAP_corrected_MERRA/GEOSdas-2_1_4
  ops: /gpfsm/dnb51/projects/p15/iau/merra_land/precip_CPCU-CMAP_corrected_MERRA/GEOSdas-2_1_4

Which I think was sort of trying to make sense of the comments in AGCM.rc.tmpl.

The "r21c" path is definitely wrong.

The MERRA-2 path may be right, but I can't say for sure. If in doubt, we have to ask Rob or reverse-engineer the MERRA-2 ADAS tag.

The "ops" path doesn't make sense if by "ops" you mean FP. For FP, we don't do precipitation corrections or scaling.

After looking at #823 with @sshakoor1 it looks like in the control yaml currently precip_correction: is either true or false. If true we link ExtData/PCP to the merra-2 entry of the catalog.

But, since you are here maybe the right question is: What should we have in bcs_catalog.tmpl going forward? Do we need perhaps a "string" option like:

precip_correction: # none, scale, non-scaled

and then those link in a different directory to ExtData/PCP? Or do both your new scale and old...non-scaled (🤷🏼) use the same path?

The general idea is that users specify either PRECIP_FILE or PRECIP_FILE_CLIMSCALE (or neither). If you want to separate out the type of precipitation treatment ("none", "obs-correct", "clim-scale"), you could introduce such a variable, but you'd still have to provide product-specific path and file names for the "obs-correct" and "clim-scale" options.

Hardcoding the precipitation file paths and names for either MERRA-2 or M21C is less than ideal because users probably need both options for at least some time going forward. And for M21C you'd also still have to decide whether you're before or after 30 September 2025, 21z (for M21C, see GEOS-ESM/GEOSadas#441 and https://github.com/GEOS-ESM/GEOSadas/releases/tag/GEOSadas-5.30.3-M21C-7)

We just want to make sure when this gets to @rtodling at some point, he can have the right link in ExtData/PCP.

I haven't been involved in the linkbcs revisions, so not sure what the exact needs are here.

Also, I guess, what paths would you recommend for the precip_correction in the catalog. I mean, maybe only one (the merra-2) is even worth having? And perhaps r21c is just all wrong?

If there is to be a catalog, it should have both the M2 and M21C options. To be safe, the exact paths should come from the ops team.

Sorry I don't have great answers

cc: @biljanaorescanin

[gmao-rreichle]

the value for r21c is incorrect

[gmao-rreichle]

I don't think the value for "ops" makes any sense

[gmao-rreichle]

the value for "merra-2" may be ok but needs to be run by the ops group

[mathomp4]

@sshakoor1 I'm wondering if we should update the scripts to use your packtoiso.py in lines like:

$GEOSBIN/linkbcs.py --config linkbcs_config.yaml --timestamp $YEAR-01-01T00:00:00

I mean, I know you only need the year, but it wouldn't hurt to pass in the full timestamp.