[yt-users] coordinate question
Elizabeth Tasker
taskere at mcmaster.ca
Tue Aug 23 14:03:51 PDT 2011
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
>
More information about the yt-users
mailing list