[yt-users] coordinate question

[Matthew Turk]

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
>
>