[yt-dev] off axis projection in yt-3.0

Matthew Turk matthewturk at gmail.com
Sat Nov 16 22:37:35 PST 2013


Hi Nick,

On Sat, Nov 16, 2013 at 11:24 PM, nick moeckel <nickolas1 at gmail.com> wrote:
> Thank you for fixing this!
>
> I've been using it successfully on small data sets for the past day or two
> now and it's working smoothly. When I try to project on a large data set
> (1024 base grid) it's churning away for hours (8+) before I kill it. This
> seems like it's slower than it should be; is this true? If this is maybe a
> particularity of Ramses (or all octree data) I'd be happy to help out and
> work off-list with whoever the volume rendering guru is to streamline this
> functionality for these codes.
>

So this is expected, but not how I want it to be!

The reason it's doing this is that currently the volume rendering
engine is creating Python objects for each oct -- very, very slow,
although it *does* batch the IO in advance.  My reading of the source
is that for OffAxisProjection, it never builds a kD-tree, so it should
not be too hard to implement this.

I think the strategy could be to move the block traversal into Cython
for the projection sampler, feeding in the arrays of fcoords, fwidth
and the data.  This would mean adding a new function to the Sampler
object that received octrees and data.  Then, simply use this to walk
every Oct node in the Octree, updating a VolumeContainer object rather
than creating a new PartitionedGrid, and calling the sampler on that.

I won't be able to look at this in depth for a little while, but I'd
be happy to work more with you on this, and I think Sam Skillman would
also be a good collaborator too.

-Matt

> thanks again,
> Nick
>
>
> On Fri, Nov 15, 2013 at 9:34 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>>
>> This should be fixed now.
>>
>>
>> https://bitbucket.org/yt_analysis/yt-3.0/pull-request/132/fixing-leftedge-and-rightedge-for-octree/diff
>>
>>
>> On Thu, Nov 14, 2013 at 1:55 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>>
>>> One last thing - what are ds.domain_left_edge, ds.domain_right_edge, and
>>> ds.units?
>>>
>>> On November 14, 2013 at 1:53:15 PM, nick moeckel (nickolas1 at gmail.com)
>>> wrote:
>>>
>>> If I give it a center of [.25, .25, .25], and width of 0.5, then the
>>> rendered part of the plot appears centered and the right size. Labels on the
>>> axes are then off by that factor of 2.
>>>
>>> I'll have to mess around with this more tomorrow though, it's the end of
>>> my functioning for tonight.
>>>
>>>
>>> On Thu, Nov 14, 2013 at 10:37 PM, Matthew Turk <matthewturk at gmail.com>
>>> wrote:
>>>>
>>>> Okay, so my guess - although I am away from my laptop/wifi at the moment
>>>> - is that somehow the origin is being set to the wrong location.  I can
>>>> think of a few possibilities, like the width being twice what it should be
>>>> or the default being wrong. Can you try manually specifying the center a
>>>> priori? One thing that may be getting confused is the origin coordinates.
>>>> For off axis slices, the center always gets mapped to 0,0. I don't think it
>>>> works like that for off axis projections, though, where it uses a different
>>>> method of setting the center that is with respect to the full domain.
>>>>
>>>> On Nov 14, 2013 4:34 PM, "nick moeckel" <nickolas1 at gmail.com> wrote:
>>>>>
>>>>> I loaded it like so:
>>>>>
>>>>> ds =
>>>>> load('output_00010/info_00010.txt',fields=['Density','x-velocity','y-velocity','z-velocity','Pressure'])
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 14, 2013 at 10:31 PM, Nathan Goldbaum
>>>>> <nathan12343 at gmail.com> wrote:
>>>>>>
>>>>>> How did you load the data into yt?  In particular, did you use a units
>>>>>> dictionary?
>>>>>>
>>>>>> On November 14, 2013 at 1:30:46 PM, nick moeckel (nickolas1 at gmail.com)
>>>>>> wrote:
>>>>>>
>>>>>> The 100 pc box is correct, and the surface density looks fine; the
>>>>>> domain is 0 to 1 in all three dimensions.
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 10:24 PM, Matthew Turk <matthewturk at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Nick,
>>>>>>>
>>>>>>> How do the units compare to what's in your sim? Also, what is your
>>>>>>> domain extent? My guess is there is an assumption in the octree floating
>>>>>>> point coordinate generation that is missing a domain_left_edge offset.
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> On Nov 14, 2013 4:21 PM, "nick moeckel" <nickolas1 at gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>> are off axis projections expected to work for all frontends in 3.0?
>>>>>>>> Using Ramses I'm getting some curious results. e.g.
>>>>>>>>
>>>>>>>> p = OffAxisProjectionPlot(ds, [.1, .1, 1], 'Density',
>>>>>>>> north_vector=[0,1,0])
>>>>>>>>
>>>>>>>> results in
>>>>>>>>
>>>>>>>> http://i.imgur.com/TzTbh7u.png
>>>>>>>>
>>>>>>>> where the whole simulation seemt to be squished into one quadrant.
>>>>>>>>
>>>>>>>> best,
>>>>>>>>
>>>>>>>> Nick
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> yt-dev mailing list
>>>>>>>> yt-dev at lists.spacepope.org
>>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> yt-dev mailing list
>>>>>>> yt-dev at lists.spacepope.org
>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> yt-dev mailing list
>>>>>> yt-dev at lists.spacepope.org
>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yt-dev mailing list
>>>>> yt-dev at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>
>>>>
>>>> _______________________________________________
>>>> yt-dev mailing list
>>>> yt-dev at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list