[yt-dev] off_axis_projection

Sam Skillman samskillman at gmail.com
Tue Jul 3 10:10:37 PDT 2012 

Hi,

On Tue, Jul 3, 2012 at 11:01 AM, Matthew Turk <matthewturk at gmail.com> wrote:

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


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 <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
> >
> _______________________________________________
> 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/1f83444d/attachment.htm>

More information about the yt-dev mailing list