Fix several issues in file regridding; Also prevent double-flipping of vertical indices

[yantosca]

Overview

This PR fixes several remaining issues with GCPy file regridding using online weights.

1. Routine rename_and_flip_gchp_rst_vars.py now uses inquiry function is_cubed_sphere_rst_grid internally. If the data is on the GCHP checkpoint/restart grid, then data variables will be renamed according to GCHP conventions and vertical levels will be flipped so that it is positive down. Otherwise the original data will be returned unchanged. This was necessary to prevent a bug in which vertical levels were flipped twice in compare_diags.py and the example plotting scripts plot_comparisons.py and plot_single_level.py.

2. Added the boolean argument gchp_indices to routines get_ilev_coords and get_lev_coords. If true, then the coordinates will be returned as indices (e.g. 1..72), which is used for the GCHP level dimension.

3. Fixed several logic issues in file_regrid.py: a. Move flip_lev_coord_if_necessary so that it occurs before variable renaming/regridding. This prevents the flipping algorithm from being spoofed by renamed variables. b. Renamed drop_and_rename_classic_variables to drop_classic_vars, which only drops the non-regriddable variables. c. Move variable renaming into rename_restart_variables. Also improve logic so that variables are renamed properly d. Updated logic in the flip_lev_coord_if_necessary routine. Also make sure to save coordinates in the proper order. GCHP level coordinates are now saved as indices.

4. Fixed issues with command-line arguments: a. Renamed Python argument fin to filein, to match the command-line argument b. Renamed Python argument fout to fileout, to match the command-line argument c. Added verbose printout of arguments d. Remove nargs=1 from weightsdir and verbose, which turns them into a list of 1 element (instead of a scalar, which is what it should be)

Output from file_regrid.py is shown below.

TODO: Double-check the Regridding.rst instructions to make sure they are consistent with this PR. Further documentation fixes will be pushed to docs/dev.

Common use cases

GCClassic to GCHP checkpoint

GCClassic to GCClassic

GCHP checkpoint to GCHP checkpoint

GCHP checkpoint to GCHP checkpoint, stretched grid:

NOTE: Not sure if this is a plotting issue or a regridding issue.

GCHP checkpoint to GCClassic

Less common use cases (shown for completeness)

I wanted to show these cases, just to show that the regridding seems to work OK. Some editing of variable names may still be needed. In any case, these are not the usual use case so I think it's OK.

GCHP checkpoint to GCHP diagnostic

GCHP diagnostic to GCHP checkpoint

GCHP diagnostic to GCHP diagnostic

GCClassic to GCHP diagnostic

GCHP diagnostic to GCClassic

[lizziel]

I am using this to create a GCHP restart from GC-Classic and noticed this output 6 times: using dimensions ('lat', 'lon') from data variable TropLev as the horizontal dimensions for this dataset.

Is this needed? Could we suppress it?

[yantosca]

As suggested by @lizziel, we now prevent regridding to/from stretched-grids for the time being, as the stretched-grid plots above indicate some sort of error (which may be either regridding or plotting). Revisit this sometime in the future.

The error looks like:

Traceback (most recent call last):
  File "/n/holyscratch01/jacob_lab/ryantosca/data/Restarts_Out/./rst.py", line 216, in <module>
    main()
  File "/n/holyscratch01/jacob_lab/ryantosca/data/Restarts_Out/./rst.py", line 155, in main
    file_regrid(
  File "/n/home09/ryantosca/python/gcpy/gcpy/file_regrid.py", line 111, in file_regrid
    raise RuntimeError(msg)
RuntimeError: Regridding to or from cubed-sphere stretched grids is
currently not supported.  Please use the offline regridding
method described in the Regridding section of gcpy.readthedocs.io.

[yantosca]

I am using this to create a GCHP restart from GC-Classic and noticed this output 6 times: using dimensions ('lat', 'lon') from data variable TropLev as the horizontal dimensions for this dataset.

Is this needed? Could we suppress it?

Thanks @lizziel. I think that is coming in from ESMF. I am not sure how to suppress it. It doesn't appear to be generated by xESMF (at least as far as I can tell from looking through the source code).

[yantosca]

Update: the "Using dimensions..." warnings is in xESMF (see frontend.py). I have tried to disable the warnings but somehow they still come up.