Add coordinate name options to wrf/util.py

[jaredalee]

Hi, I'm trying to use wrf.cartopy_xlim and wrf.cartopy_ylim to get the cartopy map projection parameters properly set using non-WRF data on a curvilinear grid that is WRF-like (separately, I regridded data from a lat-lon rectangular grid to a curvilinear grid). I have xarray DataArrays with coordinates assigned, but my coordinates are called latitude and longitude, rather than XLAT and XLONG, because I was trying to be more cf-compliant. After reading in my data array o3, using this command:

o3 = ds.cams_o3
print(o3)

yields this output:

<xarray.DataArray 'cams_o3' (lat: 265, lon: 442)>
[117130 values with dtype=float64]
Coordinates:
    latitude   (lat, lon) float32 ...
    longitude  (lat, lon) float32 ...
    times      datetime64[ns] ...
Dimensions without coordinates: lat, lon
Attributes:
    units:        ppb
    description:  lowest model level ozone concentration

However, then when I ran this command:

cart_xlim = wrf.cartopy_xlim(var=o3)

It gave me this error:

Traceback (most recent call last):
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/xarray/core/dataarray.py", line 731, in _getitem_coord
    var = self._coords[key]
KeyError: None

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/wrf/util.py", line 3193, in geo_bounds
    lats = to_np(var_coords[latname])
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/xarray/core/coordinates.py", line 333, in __getitem__
    return self._data._getitem_coord(key)
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/xarray/core/dataarray.py", line 735, in _getitem_coord
    self._coords, key, self._level_coords, dim_sizes
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/xarray/core/dataset.py", line 155, in _get_virtual_variable
    raise KeyError(key)
KeyError: None

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "plot_cams_regrid.py", line 177, in <module>
    main()
  File "plot_cams_regrid.py", line 163, in main
    cart_xlim = wrf.cartopy_xlim(var=o3)
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/wrf/util.py", line 3754, in cartopy_xlim
    cache)
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/wrf/util.py", line 3309, in _get_wrf_proj_geobnds
    geobnds = geo_bounds(var)
  File "/glade/work/jaredlee/conda-envs/my-npl-ml/lib/python3.7/site-packages/wrf/util.py", line 3195, in geo_bounds
    raise ValueError("'var' object does not contain a latitude "
ValueError: 'var' object does not contain a latitude coordinate

The offending line in wrf.util.geo_bounds is this:

latname, lonname, _ = _find_coord_names(var_coords)

That leads to this code block in wrf.util._find_coord_names:

    try:
        lat_coord = [name for name in _COORD_VARS[0::2] if name in coords][0]
    except IndexError:
        lat_coord = None

That traced the problem to the top of wrf/util.py, where this is defined:

_COORD_VARS = ("XLAT", "XLONG", "XLAT_M", "XLONG_M", "XLAT_U", "XLONG_U",
               "XLAT_V", "XLONG_V", "CLAT", "CLONG")

Notice that that does not include 'latitude', 'lat', 'longitude', or 'lon' as options. So when I tested this code:

latname, lonname, _ = wrf.util._find_coord_names(o3.coords)
print(latname)
print(lonname)

I got this output:

None
None

But when I use this code:

o3 = o3.rename({'latitude':'XLAT', 'longitude':'XLONG'})
latname, lonname, _ = wrf.util._find_coord_names(o3.coords)
print(latname)
print(lonname)

Then I get this output:

XLAT
XLONG

So here's my request: Can all the definitions that are listed here near the top of wrf/util.py be expanded to include cf-compliant coordinate names, such as latitude and longitude? That would allow these routines to work on more than just strictly WRF-formatted variables and output files, which in turn would allow for much easier and more accurate plotting with cartopy.

_COORD_PAIR_MAP = {"XLAT": ("XLAT", "XLONG"),
                   "XLONG": ("XLAT", "XLONG"),
                   "XLAT_M": ("XLAT_M", "XLONG_M"),
                   "XLONG_M": ("XLAT_M", "XLONG_M"),
                   "XLAT_U": ("XLAT_U", "XLONG_U"),
                   "XLONG_U": ("XLAT_U", "XLONG_U"),
                   "XLAT_V": ("XLAT_V", "XLONG_V"),
                   "XLONG_V": ("XLAT_V", "XLONG_V"),
                   "CLAT": ("CLAT", "CLONG"),
                   "CLONG": ("CLAT", "CLONG")}


_COORD_VARS = ("XLAT", "XLONG", "XLAT_M", "XLONG_M", "XLAT_U", "XLONG_U",
               "XLAT_V", "XLONG_V", "CLAT", "CLONG")

_LAT_COORDS = ("XLAT", "XLAT_M", "XLAT_U", "XLAT_V", "CLAT")

_LON_COORDS = ("XLONG", "XLONG_M", "XLONG_U", "XLONG_V", "CLONG")

_TIME_COORD_VARS = ("XTIME",)

Jared

[michaelavs]

Hi @jaredalee,
Thank you for taking the time to contribute to WRF-Python!
Orhan and I discussed this proposed addition at a bit more depth yesterday and ultimately decided that we don't think updating the software with your suggested changes would be necessary within the scope and goal of WRF-Python. The primary reason is that the software is designed to work solely with WRF output files, and any compatibility with other dataset types is more of an additional benefit but not the overall goal. That said, if the WRF model were to be updated to use those variable naming conventions, we would definitely look into adding those variable names at that time. If this has already happened and we were just not aware of it, definitely let us know and we will take a second look at these updates!

I do want to also note that because you opened this issue, and listed the work around you used, anyone with a similar dataset and/or issue as you will now be able to see how you overcame the issue and possibly do the same for their own code. So, while we aren't moving forward with your proposed changes at this time, your contribution here will still be beneficial to the broader community!