Isallobaric Wind #641
Comments
jrleeman
added
Area: Calc
|
Does Bluestein 1992 or 1993 have this (since I think we have been citing those texts for many of the dynamics calculations), and if so, what page? |
|
I wouldn't be surprised if it is in there and/or Holton. All of these are on the shelf in my office, feel free to borrow. |
|
It's in Bluestein 1992 at the bottom of p. 173, the first term of (4.1.98). |
|
This one is tricky because of the time derivative. By the way, it seems the current declarative interface is limited to one time (please correct me if I'm wrong). In GEMPAK, you would specify two times to plot this (the endpoints of the time interval). Similarly, in GEMPAK you would specify two levels for all the layer-based calculations (such as the thermal wind). Are there plans to generalize the declarative interface to allow these kinds of calculations, or should I open an issue? |
|
@sgdecker I think we're seeing two options here in general:
We're not necessarily wanting to have an entire domain specific language for specifying calculations like GEMPAK did. That's what Python is for. |
|
Would possible implementations be limited to functions? I'm wondering about a calling convention like (my time strings may not be correct syntax): I suppose this could be a function: And the isallobaric wind (or any other computation that requires a time interval) would have a similar interface. |
|
Couldn't |
|
Ahh, I looked at the GEMPAK Conversion Guide too quickly. That looks correct. BTW, what's the proper process to turn the "Tested against GEMPAK" column from red to green? Maybe open an issue that demonstrates the equivalence and a linked pull request that edits the table? |
|
I'd say just the PR. If one is feeling particularly motivated, adding a test case for the relevant function that tests with values validated from GEMPAK? (Depends if that's meaningfully different from existing tests.) |
|
Actually, Given the coarse time resolution in most gridded datasets, this is somewhat of a limitation. For |
|
It's not that one is right and the other is wrong, but they are different. By the way, as I try to see how different the results are, I am noticing that import datetime
import xarray as xr
from metpy.io import GempakGrid
from metpy.calc import first_derivative
from metpy.plots import ContourPlot, MapPanel, PanelContainer
MODEL = '/ldmdata/gempak/model/'
gem_data = GempakGrid(MODEL + 'nam/21082312_nam211.gem')
heights = gem_data.gdxarray(parameter='hght', level=500, coordinate='pres')
z_ds = xr.concat(heights, dim='time')
data = z_ds.sel(time=slice('2021-08-23-12:00','2021-08-24-12:00',2))
print(data)
dzdt = first_derivative(data, axis='time')
print(dzdt)
# Simple plot as sanity check works
#dzdt.sel(time='2021-08-24-00:00').plot()
# Try a more complete plot with declarative interface
ht_fall = dzdt.sel(time='2021-08-24-00:00').rename('dzdt') * 1e4
cntr = ContourPlot()
cntr.data = ht_fall
cntr.field = 'dzdt'
cntr.level = 500
cntr.time = datetime.datetime(2021,8,24)
cntr.contours = list(range(-20, 20, 4))
cntr.linecolor = 'black'
cntr.linestyle = 'solid'
cntr.clabels = True
panel = MapPanel()
panel.area = [-125, -74, 20, 55]
panel.projection = 'lcc'
panel.layers = ['states', 'coastline', 'borders']
panel.title = 'dzdt at {plot_time}'
panel.plots = [cntr]
pc = PanelContainer()
pc.size = (15, 15)
pc.panels = [panel]
pc.show()with output: |
|
Try not setting That's a good point about the 2 vs. 3 points. I'd be happy to merge something adding something functionally equivalent to |
|
OK, I was overspecifying things. I also needed to drop the time specification, but my revised version still isn't happy: import datetime
import xarray as xr
from metpy.io import GempakGrid
from metpy.calc import first_derivative
from metpy.plots import ContourPlot, MapPanel, PanelContainer
import cartopy.crs as ccrs
GRID211 = ccrs.LambertConformal(central_longitude=-95, standard_parallels=[25,25])
MODEL = '/ldmdata/gempak/model/'
gem_data = GempakGrid(MODEL + 'nam/21082312_nam211.gem')
heights = gem_data.gdxarray(parameter='hght', level=500, coordinate='pres')
z_ds = xr.concat(heights, dim='time')
data = z_ds.sel(time=slice('2021-08-23-12:00','2021-08-24-12:00',2))
dzdt = first_derivative(data, axis='time')
ht_fall = dzdt.sel(time='2021-08-24-00:00') * 1e4
ht_fall.attrs['crs'] = GRID211 # Error occurs with or without this line
cntr = ContourPlot()
cntr.data = ht_fall
cntr.level = 500
cntr.contours = list(range(-20, 20, 4))
cntr.linecolor = 'black'
cntr.linestyle = 'solid'
cntr.clabels = True
panel = MapPanel()
panel.area = [-125, -74, 20, 55]
panel.projection = 'lcc'
panel.layers = ['states', 'coastline', 'borders']
panel.title = 'dzdt at {plot_time}'
panel.plots = [cntr]
pc = PanelContainer()
pc.size = (15, 15)
pc.panels = [panel]
pc.show()With output: This is drifting away from the original issue, but I am attempting to understand in general how to combine calculations with |
|
Change: ht_fall.attrs['crs'] = GRID211to ht_fall.metpy.assign_crs(grid_mapping_name='lambert_conformal_conic',
standard_parallel=[25, 25], longitude_of_central_meridian=-95)See the xarray tutorial. This uses the names from CF metadata. Should the parameters of the grid be within the GEMPAK file somewhere? |
|
Thanks for the pointer to the documentation! I think there are two issues:
|
|
I have success with the simple case! import xarray as xr
from metpy.io import GempakGrid
from metpy.plots import ContourPlot, MapPanel, PanelContainer
MODEL = '/ldmdata/gempak/model/'
gem_data = GempakGrid(MODEL + 'nam/21082312_nam211.gem')
heights = gem_data.gdxarray(parameter='hght', level=500, coordinate='pres')
z_ds = xr.concat(heights, dim='time')
# This try fails with AttributeError: 'MetPyDataArrayAccessor' object has no attribute 'parse_cf'
# z_ds = z_ds.metpy.parse_cf()
z_ds = z_ds.metpy.assign_crs(grid_mapping_name=z_ds.grid_mapping_name,
standard_parallel=z_ds.standard_parallel,
longitude_of_central_meridian=z_ds.longitude_of_central_meridian,
latitude_of_projection_origin=z_ds.latitude_of_projection_origin)
z500 = z_ds.metpy.sel(time='2021-08-23 12:00', vertical=500)
cntr = ContourPlot()
cntr.data = z500
cntr.contours = list(range(5400, 6000, 60))
cntr.linecolor = 'black'
cntr.linestyle = 'solid'
cntr.clabels = True
panel = MapPanel()
panel.area = [-125, -74, 20, 55]
panel.projection = 'lcc'
panel.layers = ['states', 'coastline', 'borders']
panel.title = '500-mb heights'
panel.plots = [cntr]
pc = PanelContainer()
pc.size = (15, 15)
pc.panels = [panel]
pc.show()But I am confused why I will move on to the ddt/ |
|
@sgdecker The reason |
|
Hope you both don't mind me chiming in here:
This won't be able to use Also, not to prematurely generalize, but this strikes me as something that falls under the alternative calculations (#142) area. Perhaps some careful thought here in the API can lead the way for other alternative calculations?
I'd consider this a bug in the GEMPAK reader. I'm not aware of attributes containing the grid mapping details being valid on the variable (DataArray) itself. Instead, since we're building this from a
Correct, calculations stripping attributes is intended behavior, because it is not safe to assume attributes are still valid on the output (they represent different physical variables). At least in my understanding, things that are preserved across operations are necessarily more coordinate-like, so it makes sense (like
Since CF grid mappings work by reference to another variable on the dataset, it doesn't make sense for |
|
Oh wait, it looked like @dopplershift beat me to it on those points. |
|
OK, the Actually, the comparison is a lot closer than I thought it would be (at least for this case): The one use case where it would still be worthwhile to have a And I see the new comments as well. I think the action items are:
|
Based on some of my travails from Unidata#641.
|
Hi all, I wanted to follow up on the ddt and isallobaric wind function action items from August 2021. I am looking to plot the various components of the ageostrophic wind including the isallobaric/isallohypsic wind. There is already an existing function for the inertial advective wind which is great - thank you! I have some preliminary working code for both the isallobaric and inertial diabatic terms, but upon looking through this discussion on ddt I am unsure of how accurate some of my calculations are. If ddt and the isallobaric wind have already been developed, I would really appreciate using those functions as opposed to reinventing the wheel. At this point, I wonder if it would be easier to simply calculate both the isallobaric and inertial advective terms and subtract those from the ageostrophic wind to get the inertial diabatic component since calculating the diabatic heating rate is quite a process. |
AMS glossary cites Haurwitz, B. 1941. Dynamic Meteorology. 155–159., but I'm sure Holton or similar will have this as well.
GEMPAK Docs
ISAL Isallobaric wind
ISAL ( S ) = [ - DDT ( v (GEO(S)) ) / CORL,
DDT ( u (GEO(S)) ) / CORL ]
The text was updated successfully, but these errors were encountered: