Hi,
On Tue, Jul 3, 2012 at 11:01 AM, Matthew Turk
Hey Sam,
On Tue, Jul 3, 2012 at 12:58 PM, Sam Skillman
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.
Okay. It sounds like interpolated off-axis will never have this capability because of the way field parameters are tied into the data object, and not the field, correct? If so, I could attempt to wrap the AMRKDTree into an AMR3DData object in the future if that was something people want.
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.
Okay. I understand it adds more complexity to toss in the isinstance, but it would be easy to implement. I don't have an opinion on this.
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?
Yeah, I think that's fine. I included it there just because that's the
way it is now. I'm pretty you and I are the only ones who have used it so far anyways, and I usually just control using the env OMP_NUM_THREADS.
-Matt
Sam
On Mon, Jul 2, 2012 at 6:47 PM, Nathan Goldbaum
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
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
more advanced recipe might go through the steps of building the
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
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@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
more advanced recipe might go through the steps of building the
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
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
in there. A source, source. there. A source, source. the
least the method of calling functionality. I, for one, really appreciate it!
Cameron
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4ff240027592279525482!
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org