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,
# How many dimensions along each
# And any fields to preload
(this is optional!)
num_ghost_zones = 3)
origin='lower', interpolation='nearest', aspect=aspect, extent=[min_x,
max_x, min_y, max_y])
Matthew Turk wrote:
The imshow command in matplotlib normally puts the origin in the upper
left. Change your call to imshow to include the argument:
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
On Mon, Aug 22, 2011 at 7:09 PM, Elizabeth Tasker
> 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
> I then cut out a covering_grid centred on each object that is 2 kpc in
> 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
> numbers. (The image has shifted down and the numbers way up).
> It looks to me that this should be flipped somehow (although
> 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,
> allcloudcores = contours #cores defined by contour 0
> thiscore = allcloudcores[c]
> core_com = 
> for c in range(ncores):
> extractLE = 
> extractRE = 
> extractDims = 
> min_x, max_x = thiscore.quantities["Extrema"]("x")
> min_y, max_y = thiscore.quantities["Extrema"]("y")
> min_z, max_z = thiscore.quantities["Extrema"]("z")
> 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))
> extractRE.append(min(max_y+1.0, thiscore.pf.domain_right_edge))
> extractRE.append(min(max_z+1.0, thiscore.pf.domain_right_edge))
> for dim in range(3):
> extractCube = pf.h.covering_grid(extract_level,
> num_ghost_zones = 3)
> plotfig = pylab.figure()
> extent=[extractLE, extractRE, extractLE, extractRE])
> 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], core_com[m]),
> 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?
> yt-users mailing list
yt-users mailing list