You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a question on this as I'm working through a potential implementation:
Going on our past assumption of implementing GEMPAK's CIRC as projected_winds (finding the vertical and cross-section-tangential components of the 3D wind), I'm not sure that this would be that practical of a function until there is some form of systematic variable recognition. This is because, right now, this function would require the user specifying DataArrays for each of the 3 wind components, and if they have those picked out, they already have the vertical, and can just use a basic tangential_component function to get the tangential component of the horizontal wind.
So, would it be okay to put this on hold until MetPy has some kind of systematic variable identification from a xr.Dataset? Or is there a use case that I'm missing?
What the GEMPAK CIRC function does is take omega as the vertical component (so units of Pa/s or the like) and figures out how the arrows should look so that they are parallel to the trajectory of air parcels in the plane of the cross section. I don't see an example in the gallery showing a cross section with a vertical component (https://unidata.github.io/MetPy/latest/examples/cross_section.html#sphx-glr-examples-cross-section-py has barbs with an up-down component, but that doesn't represent vertical motion), but maybe its there and I just haven't found it?
BTW, should I open an issue requesting a declarative interface to cross sections (analogous to GDCROSS for gridded data and SNCROSS for observed soundings)?
There's no example using wind barbs with a vertical component. You should be able to replace u/v in the call to barbs with an appropriately scaled version of omega/w.
Regarding GDCROSS, #1709 is what you're looking for.
Activity
jthielen commentedon Jul 10, 2018
I have a question on this as I'm working through a potential implementation:
Going on our past assumption of implementing GEMPAK's
CIRCasprojected_winds(finding the vertical and cross-section-tangential components of the 3D wind), I'm not sure that this would be that practical of a function until there is some form of systematic variable recognition. This is because, right now, this function would require the user specifying DataArrays for each of the 3 wind components, and if they have those picked out, they already have the vertical, and can just use a basictangential_componentfunction to get the tangential component of the horizontal wind.So, would it be okay to put this on hold until MetPy has some kind of systematic variable identification from a
xr.Dataset? Or is there a use case that I'm missing?dopplershift commentedon Jul 11, 2018
That seems reasonable to me.
sgdecker commentedon Aug 23, 2021
What the GEMPAK
CIRCfunction does is take omega as the vertical component (so units of Pa/s or the like) and figures out how the arrows should look so that they are parallel to the trajectory of air parcels in the plane of the cross section. I don't see an example in the gallery showing a cross section with a vertical component (https://unidata.github.io/MetPy/latest/examples/cross_section.html#sphx-glr-examples-cross-section-py has barbs with an up-down component, but that doesn't represent vertical motion), but maybe its there and I just haven't found it?BTW, should I open an issue requesting a declarative interface to cross sections (analogous to GDCROSS for gridded data and SNCROSS for observed soundings)?
dopplershift commentedon Aug 23, 2021
There's no example using wind barbs with a vertical component. You should be able to replace u/v in the call to
barbswith an appropriately scaled version of omega/w.Regarding GDCROSS, #1709 is what you're looking for.
sgdecker commentedon Aug 23, 2021
OK, thanks for this and your other comment!