Add Stretched Cube Sphere option to BCS package

[biljanaorescanin]

In support of the Hazardous Weather Testbed ( HWT project) @atrayano implemented stretched grid capability. Original implementation he shared was done for old boundary conditions package so it had to be redone for python version.

This current implementation offers these choices:

Choose Stretched_Cubed-Sphere grid option:
Name Stretch Factor Lat Lon Resolution Choices
---------- ------------- ------------ ------------- ---------------------
SG001 2.5 39.5 - 98.35 c270, c540, c1080 and c2160
SG002 3.0 39.5 - 98.35 c1536

Output grid name will have stretched grid identifier for example: CF1080x6-SG001_CF1080x6C

I'm reproducing this this PR set currently staged and used from here: /discover/nobackup/projects/gmao/osse2/stage/BCS_FILES/CF1080x6C_CF1080x6C

[biljanaorescanin]

@gmao-rreichle and @weiyuan-jiang one question:
I wasn't sure do we want to add new identifier with the tile file name or just the output name so now its just at output level. Let me know if I need to change this.
Example tile file is still CF1080x6C_CF1080x6C-Pfafstetter.til and not "CF1080x6C-SG001_CF1080x6C-Pfafstetter.til

[mathomp4]

I suppose one question I've had is should we be more specific with the naming scheme? That is instead of SG001 something like lat_x_lon_x_stretch?

Also, I think these are for longitude of -98.35 as they are over CONUS.

[biljanaorescanin]

I suppose one question I've had is should we be more specific with the naming scheme? That is instead of SG001 something like lat_x_lon_x_stretch?

Also, I think these are for longitude of -98.35 as they are over CONUS.

@mathomp4 good catch for -98.35! I will fix this!

I think @gmao-rreichle can comment more but his idea is to leave flexibility if this changes we can easily add other lats /lons. And not have super long name for boundary conditions.

[gmao-rreichle]

I suppose one question I've had is should we be more specific with the naming scheme? That is instead of SG001 something like lat_x_lon_x_stretch?

Also, I think these are for longitude of -98.35 as they are over CONUS.

@mathomp4: As @biljanaorescanin said, the string that identifies the particular Stretched CS Grid would have to be rather long, and we only have a single underscore that separates the atm grid resolution from the ocean grid resolution in the bcs naming convention. Using something like lat_x_lon_x_stretch would introduce additional underscores that would mess up the parsing of the resolution string, and without the underscores the string would be even harder to interpret. But I'm open to suggestions.

[biljanaorescanin]

I've tested this and with this last commit I can reproduce all options Bill uses. We can also run all other combinations and CS grid is zero diff.

[biljanaorescanin]

This PR was tested after last commit on Friday Sept 15th.
It is zero diff for CS grid and zero diff to what Bill was using for stretched grid. I've tested tripolar grid options as well and those are zero diff.
Only boundary conditions set I can't confirm is zero diff is the new option stretched grid with Tripolar (we don't have reference for it) for example: CF0270x6C-SG001_M6TP1440x1080 but we are able to run it and all looks like its working.

Since all code changes are in boundary conditions this is trivially zero diff for GCM.

[gmao-rreichle]

@sdrabenh : This PR is ready for merging. I approved it, and my approval should have counted towards the @GEOS-ESM/surface-preproc-team, but that failed again. I guess @mathomp4 can super-approve, assuming the two of you -- as part of the @GEOS-ESM/python-transition-team -- are ok with the python changes.

[mathomp4]

Ahh. @gmao-rreichle I just removed you and readded you to @GEOS-ESM/surface-preproc-team . And Github Seems to have liked that.

[gmao-rreichle]

@mathomp4: On the PR landing page, I had just noticed a request for my review, despite my earlier approval and the page showing a green checkmark next to my name. I went ahead and approved again, which I thought then took care of the surface-preproc approval. Not sure whether your action of removing and re-adding me prompted the 2nd review button, or whether it was something else. Also, I do remember that you did the removing/re-adding a few weeks ago when we were in a similar situation. So whatever the removing/re-adding might fix, it doesn't seem to last, sadly. In any case, I think we're good to go - provided there aren't any objections to py changes.

[mathomp4]

Python looks good. I mean, I assume it was tested.