Visualization of MPAS and CAM-SE native/unstructured grid geometry

[cdeciampa]

At the suggestion of @philipc2 some months back, I have successfully modified his Polymesh code to plot the native grids of MPAS and CAM-SE (ne30) using Holoviews' Polygons. I also added a couple of features, such as:

1. Ensuring counter-clockwise winding order of the polygons for proper plotting (required by both Holoviews/Datashader and Matplotlib). I wasn't sure if this was redundant, but I included it all the same and it doesn't take more than a couple of seconds with numpy, anyway.
2. For MPAS, I included a function to "fix" the polygon node/vertex indices. MPAS's primal grid is quasi-hexagonal, with some 3-, 4-, and 5-sided shapes. The original verticesOnCell values filled those last 1-3 "empty" indices with 1, so I just replaced the empty indices with the first indices of each non-hexagon polygon (therefore connecting the polygon to itself).
3. Updating existing PyGEOS vector geometry functions to Shapely vector geometry functions (PyGEOS was absorbed by Shapely in Shapely 2.0).
4. I created a function to support both raster and vector (.svg only) image output. Vector image output takes ~24X as long (12 minutes vs 35 seconds).

I wanted to share my code for those that were seeking solutions to visualize MPAS and CAM-SE's native grids in Python until they are supported by UXarray, as well as demystify Holoviews' somewhat well-kept secret of its plotting kwargs. For CAM-SE at 25 km resolution and MPAS at 3 km resolution, it takes approximately 2 seconds and 7 seconds, respectively, for Polymesh to connect a selected variable with its native grid dataset. Plot rendering by far takes the longest time at ~35 seconds (for MPAS).

My sample notebook can be found here and I've also included a couple of sample images below. The top two panel images are raster, while the bottom three are screenshots of vector images.

[xylar]

This is really great!

[whannah1]

@cdeciampa this is great stuff! And it seems like the performance is reasonable as well.

One minor question, how would I use scrip file data for the polymesh_df argument?

[cdeciampa]

Thank you! And polymesh_df is the output from the Polymesh().data_mesh() object. From cell [9] in the sample notebook:

# Uses Polymesh code to create polygons from mesh data
p_wsp_df = Polymesh(p_mesh_ds, h3pn_ds, model='cam').data_mesh(target_var="max_sfc_wsp", dims={}, fill="faces")

The above block can be generally written as:

polymesh_df = Polymesh(mesh_file, data_file, model='cam').datamesh(target_var="max_sfc_wsp", dims={}, fill="faces")

Backing up a bit, SCRIP data (in this case, CAM-SE converted to SCRIP from HOMME) in netCDF format is read in using xarray in the following block of code from cell [7]:

# Native parent file 
h3pn_files = glob.glob(os.path.join(parent_folder, '*h3*[!nc_remap].nc'))

# Parent mesh file
p_mesh_file = r"/gpfs/group/cmz5202/default/cnd5285/maps_and_grids/ne0np4natlanticref.ne30x4.g_scrip.nc"

# Reads in simulations, assigns to xarray dataset (with Dask parallelization)
# (This is a CAM-SE data file read in using xarray
h3pn_ds = xr.open_mfdataset(h3pn_files, parallel=True)

# Reads in mesh file (this is a CAM-SE mesh file read in using xarray)
p_mesh_ds = xr.open_dataset(p_mesh_file)

I do want to stress that my modified version of the original Polymesh code only accepts CAM-SE or MPAS. Those are the only models I use for my research and my code can't be generalized for use with other models because each model uses different naming conventions for their mesh geometry variables. If you're using CAM-SE SCRIP netCDF files, then my version of Polymesh should work right out of the box. If not, I could take a look at tweaking my code, but uxarray is planning to support more models in the coming months by converting them to UGRID conventions under the hood.

[whannah1]

Oh I see, thanks for the explanation. So you're not using the pg2 physgrid with CAM-SE?

[zarzycki]

Drive-by, but no the CAM-SE data that @cdeciampa is using for her MS is actually from VR-CAM5 simulations that are ~4 years old, so pre-physgrid (GLL nodes).

I would hope it wouldn't be too hard to essentially do the same with physgrid -- I use a SCRIP file for ne30pg3 for our CPT work (haven't tried plotting on the native mesh, admittedly I interpolate to 1x1 for quick global analysis right now :)

[whannah1]

@zarzycki thanks for the clarification.

[brhillman]

This is great, thanks for working on this! I'm thrilled to see work being done to make analysis in native unstructured grids easier.

[mt5555]

I learned about these results at the recent E3SM meeting - nice results and impressively fast! Do you happen to know how the drawing engine would compare to matplotlib's PolyCollection?

For the GLL node data (CAM-SE plots), the polygons from the SCRIP file are a little unnatural and hard to compute. There's a more natural representation where the data is given by vertices of quads. Any idea if this approach could be used to shade quadrilaterals based on vertex data (i.e. a bilinear shading?) instead of cell centered data?

[cdeciampa]

Thank you! I'm glad to hear that my work is being seen. And it's been a while since I've tried, but MPL couldn't handle the number of polygons/edges/vertices for MPAS and I ran out of RAM almost immediately, so I abandoned it in favor of using holoviz. I didn't attempt any acceleration (numba, dask, cuda, etc.), though.

As for using vertex data, my work doesn't use any type of interpolation (which was the goal), so it can't be directly applied to any process with that involved, such as bilinear shading. My version of CAM-SE only has data on the grid centroids and the grid file really just lists the centroid and vertex Cartesian coordinates, so using this process would require a serious revamp to fill in the blanks with interpolation. Not to say it couldn't be done, it's just beyond the scope of what I know and what my process was designed to do.

[philipc2]

Hi @mt5555

In addition to what @cdeciampa mentioned, we are putting some finishing touches to #354, which introduces a to_gdf method that constructs a "geometry" column that consists of an array of Polygons representing the faces of the inputted unstructured grid (can be UGRID, MPAS, SCRIP, EXODUS, etc). A sample of a visualization based off this PR is attached at the bottom of the comment.

@ifranda, our summer intern, is also compiling a notebook that compares the performance and visuals of Matplotlib's PolyCollection and Datashader's Polygon rendering. We are also looking into ways to interpolate vertex data to map onto faces as one way of shading.

Also, while a bit outdated, #225 also provides some insight into some of our visualization development.

MPAS Example

# construct geometries (polygons) paired with a 1D slide of data (currently on data that lies on each face)
gdf = uxds['SST'].to_gdf()

# hvplot wrapper for GeoDataFrame
gdf.hvplot.polygons(rasterize=True, c='d_var', height=2000, width=4000, cmap='inferno', title="SST ocean.QU.480km")

[mt5555]

Just to expand on my comment on vertex data: It's the same data, just represented as vertices instead of cell centers:
So instead of using "ne0np4natlanticref.ne30x4.g_scrip.nc", I'd like to use the same data with an alternative scrip file produced by:
./GenerateVolumetricMesh --in ne0np4natlanticref.ne30x4.g --out temp.g --np 4
./ConvertMeshToSCRIP --in temp.g --out ne0np4natlanticref.ne30x4-alternative-scrip.nc

This alternative scrip file will consist of all quads, with the original CAM-SE data given at the vertices of these quads. In my superficial browsing, it seems holoviews does sometime mention edge based data, so I think it might be possible to use it with vertex data too.

edit: I wrote the above before seeing @philipc2's comment. glad to hear about possible vertex support!

[xylar]

@mt5555, it's definitely possible. I played around with it (though not super successfully) in MPAS-Tools:
MPAS-Dev/MPAS-Tools#281 (comment)

[cdeciampa]

@mt5555 ah then yes, I misunderstood but if your data is given on the vertices, then my code can probably be tweaked to plot using the vertices without any need for interpolation.

Definitely follow uxarray's releases, though. My work was built off of @philipc2's and adapted for my MS thesis in parallel with Phillip's version being integrated into uxarray. Same base code, just different features for different needs, and my work is wrapping up while uxarray continues to develop.