Added a fixed WoF grid and the python tool to determine the write component parameters

[ywangwof]

DESCRIPTION OF CHANGES:

Added a predefined grid "WoFS_3km". Note that it is in a fixed location. In reality, it should be movable with the central latitude/longitude.

Added a python script ush/python_utils/fv3write_parms.py to help with write component parameters (especially WRTCMP_lon_lwr_left/WRTCMP_lat_lwr_left) when the domain center is moved. This script requires a python module cartopy. When Conda environment "pygraf" is activated, it will work.

It will be better to integrate this python capability that moves the grid into the workflow later. So that the workflow can decide the quilting parameters automatically whenever the domain center (ESGgrid_LON_CTR/ESGgrid_LAT_CTR) is changed.

TESTS CONDUCTED:

It is tested on Jet using Intel compiler.

DEPENDENCIES:

None

[JeffBeck-NOAA]

@ywangwof, I think this PR is ready to be merged, but we need one more reviewer. In the meantime, since this requires an environment change (loading pygraf), do you mind taking a look at the rst documentation files in the ufs-srweather-app repo and opening a PR there to update instructions for setting up a user's environment if they plan to run with this grid? The documentation PR can be merged after the release branch is created to avoid confusion.

Also, I think we can start work on a second PR to regional_workflow (again, merged after the release branch is created) that will load the Python script in this PR. We'll want to create a user-defined setting in config_defaults.sh, such as "USE_MOVEABLE_WOFS_DOMAIN=TRUE/FALSE", that, if TRUE, reads (something like) WOFS_ESG_LAT_CTR and WOFS_ESG_LON_CTR for the ESG grid center (I assume this is how you define the new domain location?), then the setup or generate script would call your Python code to get the lower left Lambert lat/lon for the write component grid.

My question, though, is when should the script be called, during workflow generation or during the make_grid step? At some point, the grid information needs to be in the var_defns.sh file, but ideally, you wouldn't want to recreate the whole workflow every time you move the grid. Therefore, if the Python script is called during the make_grid task, a user would only need to update WOFS_ESG_LAT/LON_CTR in the var_defns.sh file and rerun make_grid to move the grid in a pre-generated workflow (although, they'd still need to rerun make_orog and make_sfc_climo for the new grid as well).

@gsketefian, I'd like to hear your thoughts on this too.

[gsketefian]

As I think about this more, I'm wondering why not use the existing capability in the workflow of specifying a custom grid? It seems simpler to me to just generate a new workflow each time a new grid is needed. I'm imagining a wrapper script (that's not part of the App) that: 1) Sets all the native grid parameters except ESGgrid_LON_CTR and ESGgrid_LAT_CTR. 2) Sets the location of the WoFS grid. @ywangwof you know best how that's decided, but the end result is that the variables ESGgrid_LON_CTR and ESGgrid_LAT_CTR get set. 3) Calls the python script to set the corresponding write-component parameters. 4) Creates a config.sh file that contains the above grid information plus all other necessary workflow settings. 5) Generates a new workflow using this config.sh.

The best way might be to have a template configuration file, say config_WoFS.sh (that also wouldn't need to be part of the App), that contains all the settings that will not be changing but that has placeholders for ESGgrid_LON_CTR, ESGgrid_LAT_CTR, and the write-component parameters that will be changing. Once the grid parameters are calculated, copy config_WoFS.sh to config.sh and replace the placeholders with actual values (e.g. using sed). Then call generate_FV3LAM_wflow.sh on that config.sh.

I say this because I don't see a simple way to include more than one grid (or a changing grid) in a given experiment directory. I think it would be very confusing and convoluted. We should definitely still add the WoFS grid in this PR so the WoFS suite can be tested. We can also add the python script as a starting point and then add to it the capabilities for calculating the write-component parameters for not just Lambert but also rotated-latlon and regional-latlon write-component grids (which I currently have in the ush/NCL scripts).

One thing we should do for now is rename the python script to make it clear that it currently only works for Lambert conformal grids. Besides that, this PR looks good to me.

[ywangwof]

@gsketefian They are good suggestions. We have a way to set these parameters in config.sh. I just do not like the fact that we have to set two sets of parameters ESGgrid_LON_CTR / ESGgrid_LAT_CTR and WRTCMP_lon_lwr_left / WRTCMP_lat_lwr_left while they are dependent on each other. Once users give a domain center, the other set parameters can be determined uniquely and the workflow should help for those settings to avoid obscurity or error.

[gsketefian]

@ywangwof Yes, I agree the write-component parameters should be automatically calculated. Can you just rename the script to something like fv3write_parms_lambert.py to make it clear that for now it only works for a write-component grid that is in Lambert conformal coordinates? Otherwise this is good, so I'll approve.