Define Grid dictionary for WRFout for Python Embedding

[scatt11]

Hi there,
I am either doing something very silly on my end, or there seems to be a bug in the plot_data_plane function. I am using your python embedding functionality to plot 2-meter temperature and it is continuously plotting upside down. This leads me to believe it is has something to do with the grid dictionary I have written. However, after significant troubleshooting I have not corrected this issue.

Where ds is simply an xarray dataset that reads in a raw wrfout file. The data array being plotted looks like:

and the result is...

Everything works fine if I plot it the following way:
../../src/tools/other/plot_data_plane/plot_data_plane \ wrfout_d03_2021060700.nc \ test_wrfout.ps \ 'name="T2"; level="(0,*,*)"; file_type=NETCDF_PINT;' \ -title "WRF Z2 TMP" \ -v 4

However, I am doing some python embedding to do windspeed verifications and I decided to do this with T2 first which has so far been a worth while sanity check.

Any assistance would be greatly appreciated.

[JohnHalleyGotway]

Hi Scott, I see you have a question about python embedding of gridded data in the MET tools. I see that you'd like to derive wind speed from the U and V components from your NetCDF wrfout file. But prior to jumping into that, you're testing 2m temperature... which is an excellent idea!

First, you're doing exactly what I think you should be doing... testing your python embedding script using MET's plot_data_plane utility. By running that tool you can confirm that MET is placing your data at the right spot on the earth and orienting it correctly... which it currently is not doing.

Second, I want to call your attention to this related GitHub development issue:
dtcenter/MET#1518
When processing GRIB input files and requesting wind speed/direction, MET reads the corresponding UGRD/VGRD data and derives them for you on the fly, assuming they're not already present in the input file. But this functionality is limited to only GRIB files which follow the UGRD/VGRD naming convention. Clearly, there is a need to make this automated derivation functionality more generic. Feel free to add a comment to that issue voicing your support for that feature.

Third, getting to the actual issue at hand. While python embedding of gridded data enables the MET tools to read a wider variety of inputs, it has some downsides. When reading data from GRIB files, the MET libraries check the metadata to figure out the order in which the data is packed... top to bottom, left to right, or the reverse of either. Those flags determine the order in which the data is retrieved. In the case of python embedding, no such parsing options exist. The user serves up a 2D array of data, and MET processes it exactly as it receives it. The responsibility falls to the user to confirm that the data is oriented correctly. And that's why running plot_data_plane first is ALWAYS a good idea.

Fortunately, the fix for this is very easy. You just need to add a well-placed "-1" in the python script you're running to reverse the order of one of the dimensions. Take a look at this example script:
https://dtcenter.org/sites/default/files/community-code/met/python-scripts/read_PostProcessed_WRF.py.txt

The -1 in this line reverses the order of the data:

        met_data = data[::-1].copy()

Note that the ".copy()" function is also needed so that the "met_data" variable is a complete copy of the data in memory. And that's what MET's C++ library code needs to read this data from memory.

Please give that a try. If you get stuck, please attach a sample data file and python embedding script to this issue as a tarred-zipped file and I can look more closely at it.

[scatt11]

Hi John,
Thank you to you and the entire MET team for the timely and detailed assistance you all provide. Your suggestion worked like a charm, and I'm now frustrated for not having resolved that. Indeed I was on the right track with attempting to transpose the data while I was troubleshooting, but that logic wasn't quite what I was looking for. Also, that new feature development would be phenomenal. I will be sure to add a comment to show support for it. While python embedding is a viable workaround, it leaves plenty of room for errors (like the one I was just experiencing). Plus the 2D limitations with python embedding make things way more tedious and way less streamlined.

[JohnHalleyGotway]

Great, glad you got this all sorted out. Thanks for selecting my previous response as the "Answer" and thanks for commenting on dtcenter/MET#1518.

We've found that it's difficult to track new posts to previously "Answered" discussions. So at this point, I'm going to "Lock" this Discussion to prevent future posts. That's how we encourage users to open new discussions for new questions. Feel free to do so if more questions arise.