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

nick moeckel nickolas1 at gmail.com
Sat Nov 16 22:59:10 PST 2013 

Awesome. Whenever you or Sam have a bit of time for this, drop me a line.


On Sun, Nov 17, 2013 at 7:37 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20131117/0d5f7e09/attachment.html>

More information about the yt-dev mailing list