-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geostrophic wind appears off for NARR #1275
Comments
Would you be able to post links to the dataset files used in your two examples? I cannot find anything immediately wrong with your geostrophic wind calculation, so it may be something incorrect in your coordinate/projection metadata in the files, or in the plotting after the calculation. In either case, I think it would be very good to try figuring out the issue soon, since there will be work on the kinematics calculations (like geostrophic wind here) in the next few days in preparation for the v1.0 release. |
I agree with @jthielen that it feels like a projection issue, but would you also try with |
@jthielen The NARR file is ftp://ftp.cdc.noaa.gov/Datasets/NARR/pressure/hgt.199601.nc and the CFSR file is https://rda.ucar.edu/data/ds093.1/1996/z500.gdas.199601.grb2 (login required). @jrleeman I tried using barbs and I get the same problem. I had also tried printing some values from the uwnd and vwnd arrays and confirmed that they were somewhat off, so it's not the plotting that's the problem. A couple of other students in my group had the same problem. |
@yeechianlow Thank you for passing along links to the data files! After digging into this a bit more with your data files, it luckily is just an issue with specifying the projections, and there doesn't seem to be anything wrong with the geostrophic wind calculation itself. When plotting a vector quantity with Cartopy, you need to have your coordinates be the data's native dimension coordinates. So, for CFSR, which has lat/lon dimensions, your code works perfectly, however, it fails for the y/x dimensions of the NARR data. See this notebook for an updated implementation of your code (compatible with MetPy |
@jthielen Interesting, thanks for figuring it out! What does parse_cf do? I get If it's the plotting projection that's the problem, why does accessing the wind arrays with the same indices as the height dataset also give the erroneous values and why doesn't the error also occur on the height field? To use the geostrophic wind for further calculations (such as vorticity or temperature advection), is there any special procedure I need to do to make sure the calculations are currently done on the same grid or projection? |
This provides the
It sounds like you're on version 0.11 of MetPy. The
This is the difference between a vector and a scalar field when using Cartopy. While I'm not sure if this is fully technically correct with the implementation, here's how I think of it: a vector field has two components tied to the grid of the data, so the coordinates have to be consistently defined with the components themselves (see https://scitools.org.uk/cartopy/docs/v0.15/matplotlib/geoaxes.html#cartopy.mpl.geoaxes.GeoAxes.quiver). However, with a scalar field, it's essentially just a collection of point values, so you can specify the coordinates for the points however you wish as long as you have the right transform specified.
With the calculations themselves, it is just based on having consistent grid spacings and dimension ordering. So, having Also, in not too long, MetPy v1.0 will be released, which is planned to have physically consistent kinematics calculations that automatically "do the right thing" with the coordinate data available from xarray (see #893). So, your calculation will be able to be simplified to just uwnd, vwnd = mpcalc.geostrophic_wind(hgt_500) (since |
To follow onto @jthielen 's excellent explanation, with the wind vectors (u, v), you can have them defined in one of two ways:
It's not always readily clear from the data what you're given. Regardless, when you call Based on what worked in @jthielen's notebook, I think the NARR is giving you grid-relative winds...which I think is what we've noticed in the past. @kgoebber can you confirm or correct? |
@dopplershift is correct that the NARR wind components are grid relative, not earth-relative, despite what any sparse documentation exists for the NARR grib files. This same issue arrises with NAM output as well, and they happen to be the same exact grid. There is an example in the Python Gallery that addresses this by plotting the wind barbs in their native x, y coordinate and using the information from the file about its projection to set up the proper transformation. 500-hPa Example: https://unidata.github.io/python-training/gallery/xarray_500hpa_map/ |
@dopplershift and @kgoebber Note as well that this example doesn't even use the NARR wind components, just calculated geostrophic wind, so it's automatically grid-relative. Also, having this discussion while working on #893 brought up some concerns that may be worth discussing...see my comment there. |
@jthielen @dopplershift @kgoebber Thanks for your great explanations! That resolved some headaches for me. |
No problem. It’s really a sticky problem, and unfortunately the metadata we have available isn’t sufficient to do the right thing automatically. If you happen to think up anything that would have made your life easier, please let us know. |
Hi,
The geostrophic wind function does not seem to produce accurate results on the NARR; the winds are not parallel to the height contours like they should be (top image). It seems to do better on the CFSR (bottom image). I am running Python 2.7 on a Linux server. Any help or insight on this issue would be appreciated!
Code (for NARR):
The only difference in the code for CFSR is to replace
with
Yeechian
The text was updated successfully, but these errors were encountered: