[yt-users] coordinate question

[Matthew Turk]

Hi Elizabeth,

I have inspected the output of this script:

http://paste.enzotools.org/show/1757/

and I think that it indicates that the first-pass attempt at plotting
slices through covering grids does not result in a right-hand-rule
coordinate system when using imshow.  However, it certainly shows that
the coordinates do start at the bottom left and increase to the upper
right.  I believe that yt is performing as desired, and what you may
simply need to do is either manually flip the axis with a .transpose()
following the slice, or utilize the built-in yt plotters.

-Matt

On Tue, Aug 23, 2011 at 5:48 PM, Elizabeth Tasker <taskere at mcmaster.ca> wrote:
> Slight amendment: line plots imply this is an imshow thing, not a
> covering_grid problem. That actually makes it a python problem, not a yt one
> but I'd still really appreciate any insight. Thank you :)
>
>
>
> Elizabeth Tasker wrote:
>>
>> Hi Matt,
>>
>> Thank you, that helped, but it did not entirely solve the problem. What
>> I've found is that a slice through my covering_grid does not look the same
>> as a slice done using pc.add_slice.
>>
>> I've attached links to two images to demonstrate the issue.
>>
>> http://i.imgur.com/zKVzY.png
>>
>> shows the slice through the extracted region with the positions of the
>> cores (found using extract_connected_sets on the whole hierarchy) which
>> don't line up.
>>
>> However, if you can imagine putting those same cores onto
>>
>> http://i.imgur.com/sOEvG.png
>>
>> which was made via add_slice, you can see they'd align perfectly.
>>
>> It looks like the extracted section is flipped through the line y = x. Do
>> you know if this is a feature of imshow or of covering_grid? I'm thinking it
>> *might* be the covering_grid that is inverted, since the results from my
>> data analysis don't look as expected (but it was a big calculation that I
>> could totally have just messed it up).
>>
>> I've put my calls for both below (and a more complete code is at the
>> bottom of the email).
>>
>> extractCube = pf.h.covering_grid(extract_level,
>>                                       left_edge=extractLE,
>>                                       right_edge=extractRE,
>>                                       # How many dimensions along each
>> axis
>>                                       dims=extractDims,
>>                                       # And any fields to preload (this is
>> optional!)
>>                                       num_ghost_zones = 3)
>>
>> pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)],
>> origin='lower', interpolation='nearest', aspect=aspect, extent=[min_x,
>> max_x, min_y, max_y])
>>
>> Thanks!
>>
>> Elizabeth
>>
>>
>> Matthew Turk wrote:
>>>
>>> Hi Elizabeth,
>>>
>>> The imshow command in matplotlib normally puts the origin in the upper
>>> left.  Change your call to imshow to include the argument:
>>>
>>> origin='lower'
>>>
>>> and it may fix your problem.  If you look at the yt source, this is
>>> scattered throughout to account for this.  You probably also want to
>>> supply:
>>>
>>> interpolation='nearest'
>>>
>>> -Matt
>>>
>>> On Mon, Aug 22, 2011 at 7:09 PM, Elizabeth Tasker <taskere at mcmaster.ca>
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I feel I have a co-ordinate problem.
>>>>
>>>> I have a yt script that uses extract_connected_sets to find a bunch of
>>>> contoured objects, for which I calculate the centre of mass (core_com
>>>> below).
>>>>
>>>> I then cut out a covering_grid centred on each object that is 2 kpc in
>>>> width.
>>>>
>>>> I image the slice of the covering_grid through its and over-plot the
>>>> positions of the centre of mass of the contoured objects on it.
>>>>
>>>> The problem is, they don't line up!
>>>>
>>>> cloud50.png shows the process centred on object 50. Object 50 itself is
>>>> nicely over a blob but the others are randomly scattered. Although this
>>>> is
>>>> only a slice, the z-direction of the objects differs only slightly: it
>>>> shouldn't be possible to have an object sitting over nothing (especially
>>>> when the slice effectively shows potential, which varies smoothly).
>>>>
>>>> cloud51.png shows the same process now centred on object 51. 51 is now
>>>> over
>>>> a clear blob, but you can see that the image has moved differently to
>>>> the
>>>> numbers. (The image has shifted down and the numbers way up).
>>>>
>>>> It looks to me that this should be flipped somehow (although
>>>> experimental
>>>> inverting the x-y axes have failed!), but I cannot see where the mistake
>>>> is.
>>>>
>>>> The (abbreviated) code looks like:
>>>>
>>>> contours = dd.extract_connected_sets("NegEscapeVelocity", 1, 30.0, maxv,
>>>> log_space=False)
>>>> allcloudcores = contours[1][0] #cores defined by contour 0
>>>> thiscore = allcloudcores[c]
>>>>
>>>> core_com = []
>>>> for c in range(ncores):
>>>>  core_com.append(thiscore.quantities["CenterOfMass"]())
>>>>
>>>>
>>>> extractLE = []
>>>> extractRE = []
>>>> extractDims = []
>>>>
>>>> min_x, max_x = thiscore.quantities["Extrema"]("x")[0]
>>>> min_y, max_y = thiscore.quantities["Extrema"]("y")[0]
>>>> min_z, max_z = thiscore.quantities["Extrema"]("z")[0]
>>>>
>>>> extractLE.append(max(min_x-1.0, 0.0))
>>>> extractLE.append(max(min_y-1.0, 0.0))
>>>> extractLE.append(max(min_z-1.0, 0.0))
>>>>
>>>> extractRE.append(min(max_x+1.0, thiscore.pf.domain_right_edge[0]))
>>>> extractRE.append(min(max_y+1.0, thiscore.pf.domain_right_edge[1]))
>>>> extractRE.append(min(max_z+1.0, thiscore.pf.domain_right_edge[2]))
>>>>
>>>> for dim in range(3):
>>>>
>>>> extractDims.append(round((extractRE[dim]-extractLE[dim])/cellsize))
>>>>
>>>> extractCube = pf.h.covering_grid(extract_level,
>>>>                                       left_edge=extractLE,
>>>>                                       right_edge=extractRE,
>>>>                                       dims=extractDims,
>>>>                                       num_ghost_zones = 3)
>>>>
>>>> plotfig = pylab.figure()
>>>>
>>>> pylab.imshow(extractCube["NegEscapeVelocity"][:,:,int(extractDims[2]/2)],
>>>> extent=[extractLE[0], extractRE[0], extractLE[1], extractRE[1]])
>>>> colorbar = pylab.colorbar()
>>>> colorbar.set_label("Negative escape velocity [km/s]")
>>>> pylab.xlabel('x [kpc]')
>>>> pylab.ylabel('y [kpc]')
>>>>
>>>> for m in range(ncores):
>>>>    pylab.annotate('%s' % (m), xy=(core_com[m][0], core_com[m][1]),
>>>> xycoords='data')
>>>>
>>>> pylab.savefig('clouds_novel%s' % (c))
>>>>
>>>>
>>>>
>>>>
>>>> Is this a problem of where the "zero" point is in yt / enzo / python? I
>>>> was
>>>> assuming (0,0,0) is the bottom left?
>>>>
>>>> Elizabeth
>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>> yt-users at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>
>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>