[FEATURE]: Pull in coordinates from separate file

[jukent]

Description

Some WRF data does not contain the lat/lon coordinates in the same file as the data variables. This was the case in this example. There is still the added step of needing to pull in this data before XWRF can effectively do its work (it still cleans up the time coordinates nicely). I have tested this in this notebook.

Implementation

Here is a sample function that adds cleaned up lat/lon coordinates when a file is missing them:

def assign_coords_from_file(file_path, geo_path):
    #open dataset
    ds = xr.open_dataset(file_path, engine="xwrf")
    
    #open coord file
    ds_geo = xr.open_dataset(geo_path, engine="xwrf")

    #add coords
    ds_coords = ds.assign_coords(lat=ds_geo.coords['XLAT'], 
    lon=ds_geo.coords['XLONG'])

    #rename coords to match CF conventions
    ds_rename = ds_coords.rename({'south_north':'y', 'west_east':'x'})

    #drop redundant coords
    ds_clean = ds_rename.drop(['XLAT', 'XLONG', 'CLAT'])

    return ds_clean

ds = assign_coords_from_file("data/T2_RR_F_2014_08.nc", "data/wrfinput_d02")

Tests

Perhaps we need to add a test that all variable dimensions are represented by a coordinate.

Questions

How common is it for WRF data to store the coordinate information in a separate geo-file?

Are there any patterns for where this geo-file is located that we can exploit to automatically find and pull in the correct geo-file without needing it provided?

Also I noticed that XWRF does not currently rename dimension names (south_north to y, e.g.). Is this something we want to do? It is done in the example.

[bsu-wrudisill]

1. In my experience with WRFv.3.8.1+, wrfout* files have XLAT/XLONG, XLAT_U/XLONG_U, and XLAT_V/XLONG_V variables in them. Someone please correct me if I'm wrong on that.

But, as far as I know, they don't typically have the XLAT_C/XLONG_C fields, which are the lat/lons of the grid cell corners. These variables are present in the geo_em* files though. Corner locations are useful to have when doing conservative regridding (such as https://xesmf.readthedocs.io/en/latest/notebooks/Pure_numpy.html?highlight=conservative#Regridding) from one curvlinear grid to another. This isn't an operation that everyone needs to do, but it is an important one for comparing wrf outputs to other datasets.

2. I think that a lot of users probably move around/organize files before they do post-processing, so I don't think you could expect to find geo_em files in a particular place just based on the wrf input file paths

[LejoFlores]

@bsu-wrudisill is correct in that XLAT_C and XLONG_C are in the geo_em* files, but not in the wrfout* files. Having just used xesmf to regrid a bunch of other data onto my WRF grids for analysis, it would be really great to have it also parse the corners. Conservative regridding is particularly important for precipitation comparisons so any regridding doesn't add/subtract mass when comparing between WRF and other datasets.

As for renaming dimensions I think it would be good to rename here because south_north and west_east are not common in other datasets. The only challenge (this is also reflected in the underlying names of south_north and west_east) is that because WRF grids can be curvilinear, x- and y- can be ambiguous. Attached is a plot of some domains we've run in our groups and the CA one gives some sense as to how the grid dimensions can be very not south_north and west_east.

[jukent]

1. In my experience with WRFv.3.8.1+, wrfout* files have XLAT/XLONG, XLAT_U/XLONG_U, and XLAT_V/XLONG_V variables in them. Someone please correct me if I'm wrong on that.

Do you think it is fair to design XWRF to be optimized only with WRFv.3.8.1+, and maybe add support for earlier versions (with separate geo-files) later?

[kmpaul]

As for renaming dimensions, I wonder if we can use cf-xarray to handle those "non-standard" coordinate names...?

[LejoFlores]

@jukent... I think that should be fine... WRF v3.8 is already 5+ years old so I would imagine most current usage is these versions or higher. I also went back to the UGs of the previous versions and going back to v3.3 (when I first started using WRF) found that XLAT_C and XLONG_C (the grid corners) only seemed to be found in the geo_em* files in v3.8+. XLAT/XLONG, XLAT_U/XLONG_U, and XLAT_V/XLONG_V will all still be in the wrfouts* from earlier versions. So much of the functionality in XWRF will still work... but when folks need to do conservative regridding they'd need to compute the grid corners. So maybe a version check and a warning?

[kmpaul]

Yeah. That sounds reasonable.

[jukent]

Okay. Should I rename this issue to adding a WRF version check?

[jukent]

@LejoFlores Do I understand coorectly that the south_north and west_east dimensions a grid roughly aligned with the edges of the boxes? And not to the lat-lon grids?

I believe that since x and y are mapped to dimension values that are clearly defined it won't be a problem, their name isn't that important -- but we don't want to accidentally portray data to have the same x and y definitions where it does not.

[LejoFlores]

Yep! south_north and west_east will always represent the dimensions of the grid, the grid might just be rotated from a typical lat-long coordinate system.

[jukent]

@LejoFlores I too find that naming less intuitive than x and y, since those can be ambiguous but south_north implies latitude.

Do you ever have a grid tilted so strongly (45°) that the naming distinction between south_north and west_east has no meaning?

[jthielen]

While this issue pre-dates many of the features that have made it into the initial release of xWRF, I thought it would be good to revisit it (especially with an eye towards a rough roadmap going forward).

The south_north / west_east rename to y / x is indeed now a standard part of .xwrf.postprocess() (xref #14) and geo_em and met_em files have basic support (xref #14, #46). With that in mind, would it be reasonable to say that the two remaining components from this issue are the following?

• ease-of-use method(s) for merging in geo_em* coordinates into postprocessed wrfout datasets, covering use cases of
  • grid cell corners for conservative regridding
  • missing coords due to version, tweaked WRF registry, or custom data processing
• wrfout version checking / compatibility warnings

Also, wanted suggest another option (could have both) to merging in external coordinate information: would we want to support re-computation of all the grid center/wall/corner latitudes and longitudes from projection coordinates (which are in turn derived from dataset attrs like CEN_LAT and MAP_PROJ)?