<div dir="ltr">Awesome. Whenever you or Sam have a bit of time for this, drop me a line.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 17, 2013 at 7:37 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<br>
<div class="im"><br>
On Sat, Nov 16, 2013 at 11:24 PM, nick moeckel <<a href="mailto:nickolas1@gmail.com">nickolas1@gmail.com</a>> wrote:<br>
> Thank you for fixing this!<br>
><br>
> I've been using it successfully on small data sets for the past day or two<br>
> now and it's working smoothly. When I try to project on a large data set<br>
> (1024 base grid) it's churning away for hours (8+) before I kill it. This<br>
> seems like it's slower than it should be; is this true? If this is maybe a<br>
> particularity of Ramses (or all octree data) I'd be happy to help out and<br>
> work off-list with whoever the volume rendering guru is to streamline this<br>
> functionality for these codes.<br>
><br>
<br>
</div>So this is expected, but not how I want it to be!<br>
<br>
The reason it's doing this is that currently the volume rendering<br>
engine is creating Python objects for each oct -- very, very slow,<br>
although it *does* batch the IO in advance.  My reading of the source<br>
is that for OffAxisProjection, it never builds a kD-tree, so it should<br>
not be too hard to implement this.<br>
<br>
I think the strategy could be to move the block traversal into Cython<br>
for the projection sampler, feeding in the arrays of fcoords, fwidth<br>
and the data.  This would mean adding a new function to the Sampler<br>
object that received octrees and data.  Then, simply use this to walk<br>
every Oct node in the Octree, updating a VolumeContainer object rather<br>
than creating a new PartitionedGrid, and calling the sampler on that.<br>
<br>
I won't be able to look at this in depth for a little while, but I'd<br>
be happy to work more with you on this, and I think Sam Skillman would<br>
also be a good collaborator too.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
> thanks again,<br>
> Nick<br>
><br>
><br>
> On Fri, Nov 15, 2013 at 9:34 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>><br>
> wrote:<br>
>><br>
>> This should be fixed now.<br>
>><br>
>><br>
>> <a href="https://bitbucket.org/yt_analysis/yt-3.0/pull-request/132/fixing-leftedge-and-rightedge-for-octree/diff" target="_blank">https://bitbucket.org/yt_analysis/yt-3.0/pull-request/132/fixing-leftedge-and-rightedge-for-octree/diff</a><br>


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