z10 does have only a 2-D grid. What's getting us here is thinking about "once it's evaluated". Ferret doesn't fix in memory the array on its first evaluation, so if you ask for Z10[k=1], now that's a different _expression_.
Another thing we could do here is to nail down the context to work on in Z as part of the original definition, for instance,
yes? let z10 = temp[z=0:1000@LOC:10]and then you could work with z10 [k=1] or z10[k=800]. (And those are identical, since z10 does not now depend on K.)
On 12/1/2015 10:57 AM, William S. Kessler wrote:
Hi Andrew, Ryo - I don't think that was Ryo's question. What he wants is for a field defined by @loc (once it is evaluated from a 3-d field) to have the grid of a 2-d field. Of course Ferret understands it as 2-d (thus it can be plotted with SHADE), but the variable Z10 retains its 3-d grid. He would like it to be 2-d so he can refer to Z10[k=1], and get the single-z-level field. But I understand a definition like TEMP[Z=@LOC:10] to be comparable to TEMP[Z=400], namely it describes a 2-d field that can be SHADEd, but it remains part of a 3-d grid. I think it can be converted to 2-d with RESHAPE: LET Z102D = RESHAPE(Z10,X[GX=TEMP]+Y[GX=TEMP]) (No time to test this!) BillyOn Dec 1, 2015, at 9:58 AM, Andrew Wittenberg - NOAA Federal <andrew.wittenberg@xxxxxxxx> wrote: Hi Ryo, Thanks for the clearly-stated question. [All: this is a good example of how to ask a question so that it gets answered quickly. In particular, Ryo provided a working example using one of Ferret's built-in datasets, e.g. levitus_climatology, coads_climatology, or monthly_navy_winds; and also pasted in the Ferret header, which shows what Ferret version he was using, just in case it turned out to be a bug.] Note that Z=@LOC doesn't mean "search from top to bottom for 10 degC." Instead it means "search within the future evaluation context for 10 degC." So when you later specify z10[k=1], @LOC dutifully searches only over k=1; and since 10degC isn't found in the top level, it evaluates to "missing." To insulate @LOC from future contexts, specify explicit z-limits: NOAA/PMEL TMAP FERRET v6.951 (10/29/2015) Linux 2.6.32-573.7.1.el6.x86_64 64-bit - 10/30/15 1-Dec-15 12:40 yes? use levitus_climatology yes? let z10 = temp[z=0:6000@LOC:10] yes? let below_z10 = z[g=temp] LT z10 yes? shade/x=180 below_z10 yes? shade/z=400 below_z10 The relevant documentation is: http://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/variables-xpressions/XPRESSIONS#_VPINDEXENTRY_528 See also the following answer in the Ferret email archives: http://www.pmel.noaa.gov/maillists/tmap/ferret_users/fu_2006/msg00098.html which was found by searching the email archives for "missing context". Andrew On Tue, Dec 1, 2015 at 6:06 AM, Ryo Furue <furue@xxxxxxxxxx> wrote:Hi Ferret users, I'm sure there has been discussions about this issue and I searched our email archive and found some threads that touch upon it, but didn't find whether it's "solved" or not. The problem is that @LOC (and perhaps other similar transformations) doesn't properly "eliminate" the axis. For a (x,y,z) temperature field, say, you can find the depth of an isopycnal: yes? z10 = temp[z=@LOC:10] but, "SHOW GRID z10", it still has more than one gridpoints. Nevertheless, yes? fill z10[k=1] !--> undefined field yes? fill z10 !--> works! See a complete example below. This behavior looks like a bug to me. This matters. I wanted to define a mask on the basis of this variable, something like: yes? let below_z10 = if z[g=temp] lt z10 then 1 but this doesn't work because z10[k=1, 2, 3, . . .] are undefined! My temporary solution is yes? let grid = x[gx=temp] + y[gy=temp] yes? let z10_squashed = reshape(z10,grid) yes? let below_z10 = if z[g=temp] lt z10_squashed then 1 But, I guess Ferret should do this reshaping for me with @LOC. Regards, Ryo ---------------------------------------- $ ferret NOAA/PMEL TMAP FERRET v6.94 Darwin 14.1.0 - 02/26/15 1-Dec-15 19:36 yes? set data levitus_climatology yes? let z10 = temp[z=@LOC:10] yes? show grid z10 GRID GMS1 name axis # pts start end XAXLEVITR LONGITUDE 360mr 20.5E 19.5E(379.5) YAXLEVITR LATITUDE 180 r 89.5S 89.5N ZAXLEVITR DEPTH (m) 20 i- 0 5000 normal T normal E normal F yes? list/x=180/y=0 z10[k=1] VARIABLE : TEMP[Z=@LOC:10] FILENAME : levitus_climatology.cdf FILEPATH : /usr/local/ferret/data/ LONGITUDE: 179.5E LATITUDE : 0.5S DEPTH (m): 0 to 5 .... yes? list/x=180/y=0 z10 VARIABLE : TEMP[Z=@LOC:10] FILENAME : levitus_climatology.cdf FILEPATH : /usr/local/ferret/data/ LONGITUDE: 179.5E LATITUDE : 0.5S DEPTH (m): 0 to 5000 371.7 !---- temporary solution ---- yes? let grid = x[gx=temp] + y[gy=temp] yes? let z10_reshaped = reshape(z10, grid) yes? show grid z10_reshaped GRID (G002) name axis # pts start end XAXLEVITR LONGITUDE 360mr 20.5E 19.5E(379.5) YAXLEVITR LATITUDE 180 r 89.5S 89.5N normal Z normal T normal E normal F yes? list/x=180/y=0 z10_reshaped[k=1] VARIABLE : RESHAPE(Z10, GRID) FILENAME : levitus_climatology.cdf FILEPATH : /usr/local/ferret/data/ LONGITUDE: 179.5E LATITUDE : 0.5S 371.7 yes? list/x=180/y=0 z10_reshaped VARIABLE : RESHAPE(Z10, GRID) FILENAME : levitus_climatology.cdf FILEPATH : /usr/local/ferret/data/ LONGITUDE: 179.5E LATITUDE : 0.5S 371.7 yes?~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ William S. Kessler NOAA / Pacific Marine Environmental Laboratory 7600 Sand Point Way NE Seattle WA 98115 USA william.s.kessler@xxxxxxxx Tel: +1 206-526-6221 Fax: +1 206-526-6744 Web: http://faculty.washington.edu/kessler/