[yt-dev] off_axis_projection

[Matthew Turk]

Hey Sam,

On Tue, Jul 3, 2012 at 12:58 PM, Sam Skillman <samskillman at gmail.com> wrote:
> 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

Alright, let's go with this.  Until then we'll hold off on
implementing Elizabeth's request, and when it's done we can move
forward with this.

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

I think reusing bricks -- after Cameron's comment -- seems to be okay
to relegate to setting up a Camera object.

I'd also like to suggest we get rid of the num_threads and move that
into a ytcfg option, since I think it should probably be a global
setting rather than routine-by-routine, and because it'll become more
prevalent as time goes on.  Would that work for you?

-Matt

>
> 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
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>