[yt-dev] off_axis_projection

Cameron Hummels chummels at astro.columbia.edu
Mon Jul 2 16:36:24 PDT 2012


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 <javascript:;>>
>     > 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 <javascript:;>>
>     >> wrote:
>     >>>
>     >>> On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman
>     <samskillman at gmail.com <javascript:;>>
>     >>> 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 <javascript:;>>
>     >>> > 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 <javascript:;>
>     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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120702/7b213676/attachment.htm>


More information about the yt-dev mailing list