Re: [yt-dev] off_axis_projection

2 Jul 2012

      Hi Cameron,

Well, here's my thinking on it.

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.

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.

-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 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 javascript:;
...
wrote:
...
On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman javascript:;
...
...
...
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
wrote:
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 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@lists.spacepope.org javascript:;
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org