Hi,<br><br><div class="gmail_quote">On Tue, Jul 3, 2012 at 11:01 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Sam,<br>
<div class="im"><br>
On Tue, Jul 3, 2012 at 12:58 PM, Sam Skillman <<a href="mailto:samskillman@gmail.com">samskillman@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I'm catching up on this thread, but I'm confused why what I suggested before<br>
> was discarded. In the near future (~month) I see it being possible to have<br>
> the following API:<br>
><br>
> off_axis_projection(pf, center, normal_vector, width, resolution,<br>
> field, weight = None, num_threads = 0,<br>
> interpolated = False, data_source=None)<br>
><br>
> interpolated=True/False triggers ghost zone generation and kd-tree<br>
> decomposition<br>
><br>
> data_source is the same as what is used for on-axis projections<br>
<br>
</div>Alright, let's go with this. Until then we'll hold off on<br>
implementing Elizabeth's request, and when it's done we can move<br>
forward with this.</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> The only functionality that this would kill is saving a set of bricks and<br>
> supplying it like was done in the volume=, but we could even put in an<br>
> isinstance(data_source, AMRKDTree) to just have it reuse.<br>
<br>
</div>I think reusing bricks -- after Cameron's comment -- seems to be okay<br>
to relegate to setting up a Camera object.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd also like to suggest we get rid of the num_threads and move that<br>
into a ytcfg option, since I think it should probably be a global<br>
setting rather than routine-by-routine, and because it'll become more<br>
prevalent as time goes on. Would that work for you?<br>
<br></blockquote><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Matt<br>
<br>
><br>
<div class="HOEnZb"><div class="h5">> Sam<br>
><br>
><br>
><br>
> On Mon, Jul 2, 2012 at 6:47 PM, Nathan Goldbaum <<a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a>><br>
> wrote:<br>
>><br>
>><br>
>> > I'm OK with keeping the wrapper as a simple use case with very few<br>
>> > pass-through parameters to the camera object. However, I think that in<br>
>> > order for our beginner/intermediate users to be able to use more advanced<br>
>> > features (e.g. interpolation), we should make it very clear in the docs how<br>
>> > to access this. I'm thinking something like if we have a use case for<br>
>> > generating an off_axis_projection in the cookbook (using the simple<br>
>> > wrapper), we could include a link to more advanced recipes right there. A<br>
>> > more advanced recipe might go through the steps of building the source,<br>
>> > passing it to the projectioncamera, and setting a few kwargs in the<br>
>> > projectioncamera, then taking a snapshot. That way, people can still easily<br>
>> > figure out how to do these more complex operations without parsing source.<br>
>> > Nathan, what do you think?<br>
>><br>
>> I'm -0 on this course of action, if only because it means I have to look<br>
>> through the docs every time I want to make an interpolated off-axis<br>
>> projection. Is it really so bad to include an Interpolated=False keyword<br>
>> argument? From the perspective of the user this doesn't add a whole lot of<br>
>> complexity and it's pretty clear what the keyword argument does.<br>
>><br>
>> I'm +1 on not specifying data sources.<br>
>><br>
>> Nathan Goldbaum<br>
>> Graduate Student<br>
>> Astronomy & Astrophysics, UCSC<br>
>> <a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a><br>
>> <a href="http://www.ucolick.org/~goldbaum" target="_blank">http://www.ucolick.org/~goldbaum</a><br>
>><br>
>> On Jul 2, 2012, at 5:49 PM, Cameron Hummels wrote:<br>
>><br>
>> > Yo,<br>
>> >><br>
>> >> Well, two points:<br>
>> >><br>
>> >> I definitely am not suggesting removing functionality.<br>
>> >><br>
>> >> The discussion is important so that these concerns, opinions and<br>
>> >> thoughts can get aired! Your viewpoint is important as you are the heaviest<br>
>> >> user.<br>
>> >><br>
>> >> So I guess what I am getting here is that right now and for the<br>
>> >> foreseeable future we should preserve the simple wrapper code as is and not<br>
>> >> transition to specifying data sources. We could also perhaps investigate<br>
>> >> making the interpolated and non interpolated routines have different names,<br>
>> >> too. Perhaps off_axis_projection should *only* operate with interpolated<br>
>> >> dumps, and a new name be come up with for the non-interpolated? This would<br>
>> >> allow divergent development.<br>
>> >><br>
>> > I'm OK with keeping the wrapper as a simple use case with very few<br>
>> > pass-through parameters to the camera object. However, I think that in<br>
>> > order for our beginner/intermediate users to be able to use more advanced<br>
>> > features (e.g. interpolation), we should make it very clear in the docs how<br>
>> > to access this. I'm thinking something like if we have a use case for<br>
>> > generating an off_axis_projection in the cookbook (using the simple<br>
>> > wrapper), we could include a link to more advanced recipes right there. A<br>
>> > more advanced recipe might go through the steps of building the source,<br>
>> > passing it to the projectioncamera, and setting a few kwargs in the<br>
>> > projectioncamera, then taking a snapshot. That way, people can still easily<br>
>> > figure out how to do these more complex operations without parsing source.<br>
>> > Nathan, what do you think?<br>
>> ><br>
>> > So in summary, I'm OK with the switch, as long as documentation exists<br>
>> > for doing both things within the docs, and that the interpolation can still<br>
>> > be performed using a manual projectioncamera build.<br>
>> ><br>
>> > Thanks for checking with us all about shifting functionality, or at the<br>
>> > least the method of calling functionality. I, for one, really appreciate<br>
>> > it!<br>
>> ><br>
>> > Cameron<br>
>> ><br>
>> > _______________________________________________<br>
>> > yt-dev mailing list<br>
>> > <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> > <a 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>
>> ><br>
>> > !DSPAM:10175,4ff240027592279525482!<br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a 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>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a 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>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a 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>
</div></div></blockquote></div><br>