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@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 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" 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

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" 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 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@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 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" 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

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@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 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" 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 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@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 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" 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

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. thanks again, Nick On Fri, Nov 15, 2013 at 9:34 PM, Nathan Goldbaum wrote:

This should be fixed now.

https://bitbucket.org/yt_analysis/yt-3.0/pull-request/132/fixing-leftedge-an...

On Thu, Nov 14, 2013 at 1:55 PM, Nathan Goldbaum 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@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 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" 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@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@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 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" 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@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

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 wrote:

Hi Nick,

...

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

On Sat, Nov 16, 2013 at 11:24 PM, nick moeckel wrote: 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 wrote:

...

This should be fixed now.

https://bitbucket.org/yt_analysis/yt-3.0/pull-request/132/fixing-leftedge-an...

...

On Thu, Nov 14, 2013 at 1:55 PM, Nathan Goldbaum

...

wrote:

...

One last thing - what are ds.domain_left_edge, ds.domain_right_edge,

...

ds.units?

On November 14, 2013 at 1:53:15 PM, nick moeckel (nickolas1@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 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

...

...

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

and center a 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" 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 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@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@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" 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@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org