<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Matt,<br>
<br>
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.
<blockquote
cite="mid:CALO3=5EuzzC=JwoWB+EMtvTckMMMHqZOorkJiAdJmctx+XpjNw@mail.gmail.com"
type="cite">
<div>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.</div>
</blockquote>
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?<br>
<br>
<blockquote
cite="mid:CALO3=5EuzzC=JwoWB+EMtvTckMMMHqZOorkJiAdJmctx+XpjNw@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</blockquote>
<br>
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. <br>
<br>
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).<br>
<br>
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?<br>
<br>
Cameron<br>
<br>
<br>
<blockquote
cite="mid:CALO3=5EuzzC=JwoWB+EMtvTckMMMHqZOorkJiAdJmctx+XpjNw@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>-Matt</div>
<div><br>
On Friday, June 29, 2012, Cameron Hummels wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hey guys,<br>
<br>
I guess I don't entirely understand why these two
functionalities are so<br>
different, but I'll chat with you, Matt, a bit more about this
offline<br>
when I'm back at CU.<br>
<br>
Cameron<br>
<br>
> Okay.<br>
><br>
> Cameron, I know you rely upon the off_axis_projection --
would it be<br>
> okay, in your opinion, if we deprecated the interpolated
= True option<br>
> in some 2.X release and then in 3.0, if you want
interpolation, you<br>
> need to set up a projection camera yourself? I ask
because the setup<br>
> for these two is very different, and (in the spirit of
the plot<br>
> window!) I'd like to try to reduce the complexity. If
you're -1 on<br>
> this, then we can keep it the way it is.<br>
><br>
> On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <<a
moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'samskillman@gmail.com')">samskillman@gmail.com</a>><br>
> wrote:<br>
>> That capability doesn't exist yet for
interpolated=True. When that is<br>
>> possible, I would be +1 with moving from volume to
data_source.<br>
>><br>
>><br>
>> On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <<a
moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman
<<a moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'samskillman@gmail.com')">samskillman@gmail.com</a>><br>
>>> wrote:<br>
>>> > Hi all,<br>
>>> ><br>
>>> > I think the only kwarg I'd be really +1 with
getting rid of would be<br>
>>> > no_ghost. interpolated=True should just
trigger no_ghost=False, and<br>
>>> > interpolated=False doesn't use the ghost
zones no matter what. I<br>
>>> think<br>
>>> > volume should stay, especially since I think
it will soon be possible<br>
>>> to<br>
>>> > do<br>
>>> > an off_axis_projection of a data object
which would probably be fed<br>
>>> in<br>
>>> > through the volume.<br>
>>><br>
>>> Why not get rid of volume and instead supply
data_source, like<br>
>>> projections?<br>
>>><br>
>>> ><br>
>>> > Sam<br>
>>> ><br>
>>> ><br>
>>> > On Thu, Jun 28, 2012 at 9:39 AM, Matthew
Turk <<a moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Hi Elizabeth,<br>
>>> >><br>
>>> >> I agree, this makes sense.<br>
>>> >><br>
>>> >> Last night I tried to take a crack at
this, but I got very confused<br>
>>> >> with the various definitions of volume,
interpolated, etc etc, in<br>
>>> the<br>
>>> >> routine off_axis_projection. Cameron
and Sam, do you think it would<br>
>>> >> be okay if we sim<br>
<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
<a moz-do-not-send="true"
href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org"
target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
yt-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
<a class="moz-txt-link-freetext" href="http://outreach.astro.columbia.edu">http://outreach.astro.columbia.edu</a>
PGP: 0x06F886E3</pre>
</body>
</html>