[yt-dev] off_axis_projection

Mon Jul 2 17:08:45 PDT 2012

Hi Cameron,

On Jul 2, 2012 7:29 PM, "Cameron Hummels" <chummels at astro.columbia.edu>
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?

A source in this case is the second - an AMR3DData subclass just like is
specified for profiles, axis-aligned projections, etc. These objects are a
bit more flexible and can also carry field parameters more easily.

I guess it would have been more clear for me to say: the question is really
about specifying a volume vs specifying a data source.  These are different
because one is retained, the other not, and it's not at all about removing
functionality.

>
>
>>
>> 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?

No, not at all. I just think we should choose between data sources, which
are evaluated on the fly and volumes which are deliberately constructed and
held in memory persistently. This is also only about the wrapper, not about
any underlying code.  Let me be perfectly clear when I say that our
discussion (and the sentiment about removing functionality) two weeks ago
about this has not been lost from my memory.

> 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).

Well, two points:

I definitely am not suggesting removing functionality.

The discussion is important so that these concerns, opinions and thoughts
can get aired! Your viewpoint is important as you are the heaviest user.

So I guess what I am getting here is that right now and for the foreseeable
future we should preserve the simple wrapper code as is and not transition
to specifying data sources. We could also perhaps investigate making the
interpolated and non interpolated routines have different names, too.
 Perhaps off_axis_projection should *only* operate with interpolated dumps,
and a new name be come up with for the non-interpolated?  This would allow
divergent development.

>
> 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?

That is in general my preference, but I understand that I may not be in the
majority, and I understand it may not be right for every case.

My original thought was we'd get rid of the volume= kwarg, which would mean
that for the use case of repeatedly calling off_axis_projection (which is
not stateful) you'd instead need to set up a (stateful) Camera object,
which can be rotated, zoomed, etc.  This would mean that the only
difference for a workflow would be to using the camera rather than the
routine.  However, the reason I brought it up -- and wanted to discuss this
where others (like Nathan) can chime in -- is because it's important when
doing this kind of thing that input gets solicited so that users are
neither abandoned nor left out on a limb.

Maybe a better option is to leave the off_axis_projection alone, and either
not support data_sources & field_parameters, or move the entire
non-interpolated code into a separate routine, where those items *can* be
included.  Would that work for you?

-Matt

>
> 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
>
>
> _______________________________________________
> 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/20120702/c066e3ec/attachment.html>