[yt-dev] off_axis_projection

Mon Jul 2 16:35:17 PDT 2012

Sorry to chime in out of hand, but I think it would be nice to generate interpolated off-axis-projections with a keyword argument for the wrapper rather than going through the hassle of setting up the camera on my own.  I think making it so hard to generate interpolated results has the net effect of blocking non-experts from ever doing it.

Nathan Goldbaum
Graduate Student
Astronomy & Astrophysics, UCSC
goldbaum at ucolick.org
http://www.ucolick.org/~goldbaum

On Jul 2, 2012, at 4:36 PM, Cameron Hummels wrote:

> Hi Matt,
> 
> I had figured we'd talk about this offline so as to not clutter everyone's mailboxes, but if you want to discuss it here, then I'm game.
>> 
>> To conduct an interpolated off-axis projection, we need to get the ghost-zone data.  This data is relatively expensive to create, and so it makes sense to be able to keep it around for a good amount of time in between calculations -- for instance, if you want to spin around the orientation of the volume you're off-axis-projecting.  So I understand wanting to keep either the kD-tree or the homogenized volume.  This is generally an advanced operation, though.  Creating a volume also allows for specifying a source.  By creating a volume and specifying the source when doing so, you can get all of this behavior.  And then, inside the ProjectionCamera, all of the operations for spinning the view around are exposed again.  Previously, to change the viewing angle of an off-axis projection, the user had to create a volume manually, then repeatedly call off_axis_projection while resupplying the "volume" argument.  Now, off_axis_projection is a thin wrapper of the ProjectionCamera.
> What do you mean "specify a source", because to me, that is the same as specifying an already-existing volume, but you're saying the two are different?  Or does this come down to the difference between a KDtree/homogenized volume and an internal yt data volume like a sphere?
> 
>> 
>> For non-interpolated off-axis projections, we don't need ghost zones.  It's cheap to get out the grids.  The parallelism strategy is completely different.  And, we can also apply masks on the fly.  In short, it's essentially a completely different operation in the backend.  (And to keep them separate there are a bunch of conditionals inside ProjectionCamera.)
>> 
>> So where we need to direct our thoughts is on simplicity: we want to be able to provide a data_source, for two reasons: to get the field_parameters to pass through, and to allow cuts to be easily applied.  I'm wondering if it is worth the substantial added complexity in API to supply *both* volume nad data_source to a wrapper function, when that wrapper function probably shouldn't even be used anymore if "volume" is a necessary argument.
>> 
>> In short: there's no reason to use off_axis_projection with a "volume" specified, since the use case that meets is met by the ProjectionCamera that off_axis_projection thinly wraps.  So, can we just ditch that argument and replace it with a data_source?  This kind of brings up the disjoint we have between "interpolated = True" and "interpolated = False" off_axis_projections, since to make them both work from within the same routine we've had to cram a whole bunch of conditionals and additional arguments into the same set of routines.  If we add a data_source argument I just want to make sure we're not adding on an additional set of complexity where a simplification would be more appropriate.
> 
> So what you're saying is that you want to get rid of the interpolated behavior in off_axis_projections, like you wanted to do two weeks ago?  Or you're just saying that the behavior will still exist if I manually create a homogenized volume/kdtree, then manually build a projectioncamera to take snapshots of it?  If it is the second option, I guess that is fine, but I think we should make it clear how to go about doing this manually (in the docs) so that people don't flounder when trying to do anything more complex than what the very simple wrapper off_axis_projection will provide.  
> 
> I just don't want functionality to disappear, particularly when I'm still in the middle of using that functionality for a scientific paper that is about to be submitted (and may need further analysis/reproduction of interpolated off_axis_projections the way they have been historically been executed).
> 
> To understand, are we trying to make all of the wrapper functions super simplistic, and leave more complex functionality for people willing to use the cameras directly?
> 
> Cameron
> 
> 
>> 
>> -Matt
>> 
>> On Friday, June 29, 2012, Cameron Hummels wrote:
>> Hey guys,
>> 
>> I guess I don't entirely understand why these two functionalities are so
>> different, but I'll chat with you, Matt, a bit more about this offline
>> when I'm back at CU.
>> 
>> Cameron
>> 
>> > Okay.
>> >
>> > Cameron, I know you rely upon the off_axis_projection -- would it be
>> > okay, in your opinion, if we deprecated the interpolated = True option
>> > in some 2.X release and then in 3.0, if you want interpolation, you
>> > need to set up a projection camera yourself?  I ask because the setup
>> > for these two is very different, and (in the spirit of the plot
>> > window!) I'd like to try to reduce the complexity.  If you're -1 on
>> > this, then we can keep it the way it is.
>> >
>> > On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman at gmail.com>
>> > wrote:
>> >> That capability doesn't exist yet for interpolated=True. When that is
>> >> possible, I would be +1 with moving from volume to data_source.
>> >>
>> >>
>> >> On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk at gmail.com>
>> >> wrote:
>> >>>
>> >>> On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman at gmail.com>
>> >>> wrote:
>> >>> > Hi all,
>> >>> >
>> >>> > I think the only kwarg I'd be really +1 with getting rid of would be
>> >>> > no_ghost.  interpolated=True should just trigger no_ghost=False, and
>> >>> > interpolated=False doesn't use the ghost zones no matter what.  I
>> >>> think
>> >>> > volume should stay, especially since I think it will soon be possible
>> >>> to
>> >>> > do
>> >>> > an off_axis_projection of a data object which would probably be fed
>> >>> in
>> >>> > through the volume.
>> >>>
>> >>> Why not get rid of volume and instead supply data_source, like
>> >>> projections?
>> >>>
>> >>> >
>> >>> > Sam
>> >>> >
>> >>> >
>> >>> > On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk <matthewturk at gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Hi Elizabeth,
>> >>> >>
>> >>> >> I agree, this makes sense.
>> >>> >>
>> >>> >> Last night I tried to take a crack at this, but I got very confused
>> >>> >> with the various definitions of volume, interpolated, etc etc, in
>> >>> the
>> >>> >> routine off_axis_projection.  Cameron and Sam, do you think it would
>> >>> >> be okay if we sim
>> 
>> _______________________________________________
>> 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
> 
> -- 
> Cameron Hummels
> PhD Candidate, Astronomy Department of Columbia University
> Public Outreach Director, Astronomy Department of Columbia University
> NASA IYA New York State Student Ambassador
> http://outreach.astro.columbia.edu 
> PGP: 0x06F886E3
> !DSPAM:10175,4ff22eca2862958793331!
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> 
> !DSPAM:10175,4ff22eca2862958793331!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120702/5e5354c7/attachment.html>