-
|
from @spacekace: #120 (comment)
Can this issue be reopened? I am trying to use xWRF to open a CONUS404 NetCDF file and compute some variables using MetPy. I use the same code snippet as in the original post and receive the same warning. However, the traceback information is different. I have tried a number of things to fix this issue, including using wrf-python with NetCDF4 instead of xWRF, passing dx/dy/lat arrays to the mpcalc function, etc., amongst other things. I am at a loss for opening CONUS404 (ideally as an xarray for functionality with some additional calculations) and using MetPy to calculate geostrophic wind, inertial advective wind, etc. Would prefer to use this functionality rather than having to start over and compute everything from scratch. Thank you!! Code: Log: Here is the result from printing z. Again, nothing obviously unusual: |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
|
Hey @spacekace, let's continue to discuss here! So for me there is no problem applying the |
Beta Was this translation helpful? Give feedback.
-
|
The wrfout files I am using are from the published CONUS404 dataset (https://www.usgs.gov/data/four-kilometer-long-term-regional-hydroclimate-reanalysis-over-conterminous-united-states). What is the best way for me to send a file to you -- they are quite large |
Beta Was this translation helpful? Give feedback.
-
|
No Problem. If they are public, I'll download them myself. |
Beta Was this translation helpful? Give feedback.
-
|
@spacekace The Problem is that you didn't pass on a |
Beta Was this translation helpful? Give feedback.
-
|
I had tried this option and that didn't work either. Looks like the response below should work, though. Thanks for your time and assistance!! |
Beta Was this translation helpful? Give feedback.
-
|
The unfortunate thing here is that the important part of the error message is actually the initial UserWarning: geo_wind_u, geo_wind_v = mpcalc.geostrophic_wind(z.drop_vars('CLAT'))
print(geo_wind_u)Alternatively, you could tell metpy which latitude coordinate is the important one: z = ds['geopotential_height'].metpy.assign_coordinates({'latitude':'XLAT'})
geo_wind_u, geo_wind_v = mpcalc.geostrophic_wind(z)In any case, this would be worthwhile to discuss on MetPy's side, as neither solution is as clear as they should be given the existing behavior. |
Beta Was this translation helpful? Give feedback.
-
|
I really appreciate this response as dropping the CLAT fixes the issue! For clarification on the other option in case someone else stumbles upon this issue, assigning coordinates to the z variable does remove CLAT, but it also adds a new latitude coordinate which brings us back to the same issue. Code: z coordinates: Dropping the CLAT coordinate solve the issue and can be done in the geostrophic wind calculation as suggested, or prior in the initial declaration of the z variable.
Thank you and I can certainly bring this up on the MetPy side of things if that would be helpful. |
Beta Was this translation helpful? Give feedback.
-
|
And my apologies on the second method! It is specifically |
Beta Was this translation helpful? Give feedback.
-
|
@spacekace If you'd be willing to create an issue on MetPy's GitHub describing this problem and the unclear error message encountered here for this "more than one latitude coordinate" case, that would be wonderful! If not, I could also do so. |
Beta Was this translation helpful? Give feedback.
The unfortunate thing here is that the important part of the error message is actually the initial UserWarning:
More than one latitude coordinate present for variable "geopotential_height".If the extra latitude coordinate is removed, then everything should work as expected: