[yt-users] coordinate question
Elizabeth Tasker
taskere at mcmaster.ca
Wed Aug 24 07:51:56 PDT 2011
Perfect! Thank you so much.
Elizabeth
Matthew Turk wrote:
> 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
>>
>>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
More information about the yt-users
mailing list