[yt-dev] off_axis_projection

[Sam Skillman]

Hi all,

I'm catching up on this thread, but I'm confused why what I suggested
before was discarded.  In the near future (~month) I see it being possible
to have the following API:

off_axis_projection(pf, center, normal_vector, width, resolution,
                        field, weight = None, num_threads = 0,
                        interpolated = False, data_source=None)

interpolated=True/False triggers ghost zone generation and kd-tree
decomposition

data_source is the same as what is used for on-axis projections

The only functionality that this would kill is saving a set of bricks and
supplying it like was done in the volume=, but we could even put in an
isinstance(data_source, AMRKDTree) to just have it reuse.

Sam



On Mon, Jul 2, 2012 at 6:47 PM, Nathan Goldbaum <goldbaum at ucolick.org>wrote:

>
> > I'm OK with keeping the wrapper as a simple use case with very few
> pass-through parameters to the camera object.  However, I think that in
> order for our beginner/intermediate users to be able to use more advanced
> features (e.g. interpolation), we should make it very clear in the docs how
> to access this.  I'm thinking something like if we have a use case for
> generating an off_axis_projection in the cookbook (using the simple
> wrapper), we could include a link to more advanced recipes right there.  A
> more advanced recipe might go through the steps of building the source,
> passing it to the projectioncamera, and setting a few kwargs in the
> projectioncamera, then taking a snapshot.  That way, people can still
> easily figure out how to do these more complex operations without parsing
> source.  Nathan, what do you think?
>
> I'm -0 on this course of action, if only because it means I have to look
> through the docs every time I want to make an interpolated off-axis
> projection.  Is it really so bad to include an Interpolated=False keyword
> argument?  From the perspective of the user this doesn't add a whole lot of
> complexity and it's pretty clear what the keyword argument does.
>
> I'm +1 on not specifying data sources.
>
> Nathan Goldbaum
> Graduate Student
> Astronomy & Astrophysics, UCSC
> goldbaum at ucolick.org
> http://www.ucolick.org/~goldbaum
>
> On Jul 2, 2012, at 5:49 PM, Cameron Hummels wrote:
>
> > Yo,
> >>
> >> 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.
> >>
> > I'm OK with keeping the wrapper as a simple use case with very few
> pass-through parameters to the camera object.  However, I think that in
> order for our beginner/intermediate users to be able to use more advanced
> features (e.g. interpolation), we should make it very clear in the docs how
> to access this.  I'm thinking something like if we have a use case for
> generating an off_axis_projection in the cookbook (using the simple
> wrapper), we could include a link to more advanced recipes right there.  A
> more advanced recipe might go through the steps of building the source,
> passing it to the projectioncamera, and setting a few kwargs in the
> projectioncamera, then taking a snapshot.  That way, people can still
> easily figure out how to do these more complex operations without parsing
> source.  Nathan, what do you think?
> >
> > So in summary, I'm OK with the switch, as long as documentation exists
> for doing both things within the docs, and that the interpolation can still
> be performed using a manual projectioncamera build.
> >
> > Thanks for checking with us all about shifting functionality, or at the
> least the method of calling functionality.  I, for one, really appreciate
> it!
> >
> > Cameron
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> > !DSPAM:10175,4ff240027592279525482!
> >
>
> _______________________________________________
> 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/20120703/0d6c348d/attachment.html>