[yt-dev] off_axis_projection

[Nathan Goldbaum]

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