[yt-users] coordinate question

[Elizabeth Tasker]

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
>