[python #WMX-664910]: Error: Neither Quantity object nor its magnitude supports indexing
- Subject: [python #WMX-664910]: Error: Neither Quantity object nor its magnitude supports indexing
- Date: Mon, 19 Aug 2019 09:36:45 -0600
Yes, the .values command is part of the xarray syntax to get back to arrays
that we can then attach units to. This can also be handled by calling the Metpy
xarray accessor, which can then do this unit handling
for an example of .metpy.unit_array).
As far as any calculations go, the units are handled internally, so you can
feed any combination of imperial and metric units in any prefix or base state,
and it will calculate things appropriately, so you can use C or K, and Pa, hPa,
or mbar (or imperial if you wanted to).
The pressure arrays are meant to be the pressure at which the temperature and
dew point observations are recorded throughout the vertical, so no conversion
should be done to get to MSLP here.
Hope that answers your questions. Happy to answer more if you have them!
> Thanks a lot - the figure online now makes a lot more sense and my code is
> working out fine without the dy *=-1.
> I have attached the code that I use to create the Xarray with the variables
> that are used to calculate temperature advection. Hopefully you can use
> this code and download example data from the link below and see that when
> you do not put .values in the function call, there is an error. I assume
> that this is just due to the structure of Xarray.
> Download from assimilated and analyzed fields.
> I have another query actually - in the functions is it specified anywhere
> what units are expected? I am trying to calculate cape using
> most_unstable_cape_cin and it does not say what units are required,
> although I would assume it is Kelvin and Pa. Also, with regards to
> âpressureâ, is this sea level pressure or surface pressure?
> address@hidden> wrote:
> > Hi,
> > I'm surprised you needed to add the `.values` to make things work. Would
> > you be willing to share some sample data and code so I can dig in further
> > to see what was going on?
> > Yikes! That dy *= -1 line should have been removed, thanks for pointing it
> > out. I've already updated the example and rebuilt the gallery.
> > With that change, the image on the site here looks correct to me:
> > https://unidata.github.io/python-gallery/examples/850hPa_Temperature_Advection.html
> > In your example, the unexpected results may be an artifact of the
> > colormapping. You could try changing the contour intervals to see if the
> > results seem better.
> > If you still think there's something wrong with the results you're
> > getting, we can dig in further.
> > Ryan
> > > Hi,
> > > Thanks a lot for this. I updated Metpy and had the same issue but then
> > realized that I was parsing an array and so needed to send just the values
> > using Xarray.values. Otherwise I was sending all of the metadata etc
> > associated with the array and the code didnât like that.
> > > The temperature advection code is now working but I am just unsure as to
> > whether the correct result is coming out of it. Do I still need the dy*=-1?
> > (See below from code)
> > >
> > > # Because of the way the data are returned we need a negative spacing.
> > This
> > > # will be easier in the next version of MetPy.
> > > dy *= -1
> > >
> > > If I comment out this line I get a different picture. In the original
> > picture it looks like the positive and negative temperature advection are
> > the wrong way around. See the large blue area is where there is wind from
> > the south, so surely this should be warmer air and positive temperature
> > advection? The opposite is true in the top left corner where cool air is
> > being brought down from the Northeast but it is showing as warm advection .
> > > The result with dy*=-1 commented out is shown in adv2.png and doesnât
> > really make sense to me so it is probably incorrect. Is there another
> > negative sign in the code that I should correct to get the opposite signs
> > from the original calculation?
> > > Hope this makes sense!
> > Ticket Details
> > ===================
> > Ticket ID: WMX-664910
> > Department: Support Python
> > Priority: Low
> > Status: Closed
> > ===================
> > NOTE: All email exchanges with Unidata User Support are recorded in the
> > Unidata inquiry tracking system and then made publicly available through
> > the web. If you do not want to have your interactions made available in
> > this way, you must let us know in each email you send to us.
> Alison Cobb
> Postdoctoral Scholar
> Center for Western Weather and Water Extremes
Ticket ID: WMX-664910
Department: Support Python
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata
inquiry tracking system and then made publicly available through the web. If
you do not want to have your interactions made available in this way, you must
let us know in each email you send to us.