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@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.
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org