Re: [yt-dev] off_axis_projection
Hey guys, I guess I don't entirely understand why these two functionalities are so different, but I'll chat with you, Matt, a bit more about this offline when I'm back at CU. Cameron
Okay.
Cameron, I know you rely upon the off_axis_projection -- would it be okay, in your opinion, if we deprecated the interpolated = True option in some 2.X release and then in 3.0, if you want interpolation, you need to set up a projection camera yourself? I ask because the setup for these two is very different, and (in the spirit of the plot window!) I'd like to try to reduce the complexity. If you're -1 on this, then we can keep it the way it is.
On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman@gmail.com> wrote:
That capability doesn't exist yet for interpolated=True. When that is possible, I would be +1 with moving from volume to data_source.
On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
I think the only kwarg I'd be really +1 with getting rid of would be no_ghost. interpolated=True should just trigger no_ghost=False, and interpolated=False doesn't use the ghost zones no matter what. I
On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman@gmail.com> wrote: think
volume should stay, especially since I think it will soon be possible to do an off_axis_projection of a data object which would probably be fed in through the volume.
Why not get rid of volume and instead supply data_source, like projections?
Sam
On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Elizabeth,
I agree, this makes sense.
Last night I tried to take a crack at this, but I got very confused with the various definitions of volume, interpolated, etc etc, in
the
routine off_axis_projection. Cameron and Sam, do you think it would be okay if we sim
Hi Cameron, Well, here's my thinking on it. To conduct an interpolated off-axis projection, we need to get the ghost-zone data. This data is relatively expensive to create, and so it makes sense to be able to keep it around for a good amount of time in between calculations -- for instance, if you want to spin around the orientation of the volume you're off-axis-projecting. So I understand wanting to keep either the kD-tree or the homogenized volume. This is generally an advanced operation, though. Creating a volume also allows for specifying a source. By creating a volume and specifying the source when doing so, you can get all of this behavior. And then, inside the ProjectionCamera, all of the operations for spinning the view around are exposed again. Previously, to change the viewing angle of an off-axis projection, the user had to create a volume manually, then repeatedly call off_axis_projection while resupplying the "volume" argument. Now, off_axis_projection is a thin wrapper of the ProjectionCamera. For non-interpolated off-axis projections, we don't need ghost zones. It's cheap to get out the grids. The parallelism strategy is completely different. And, we can also apply masks on the fly. In short, it's essentially a completely different operation in the backend. (And to keep them separate there are a bunch of conditionals inside ProjectionCamera.) So where we need to direct our thoughts is on simplicity: we want to be able to provide a data_source, for two reasons: to get the field_parameters to pass through, and to allow cuts to be easily applied. I'm wondering if it is worth the substantial added complexity in API to supply *both* volume nad data_source to a wrapper function, when that wrapper function probably shouldn't even be used anymore if "volume" is a necessary argument. In short: there's no reason to use off_axis_projection with a "volume" specified, since the use case that meets is met by the ProjectionCamera that off_axis_projection thinly wraps. So, can we just ditch that argument and replace it with a data_source? This kind of brings up the disjoint we have between "interpolated = True" and "interpolated = False" off_axis_projections, since to make them both work from within the same routine we've had to cram a whole bunch of conditionals and additional arguments into the same set of routines. If we add a data_source argument I just want to make sure we're not adding on an additional set of complexity where a simplification would be more appropriate. -Matt On Friday, June 29, 2012, Cameron Hummels wrote:
Hey guys,
I guess I don't entirely understand why these two functionalities are so different, but I'll chat with you, Matt, a bit more about this offline when I'm back at CU.
Cameron
Okay.
Cameron, I know you rely upon the off_axis_projection -- would it be okay, in your opinion, if we deprecated the interpolated = True option in some 2.X release and then in 3.0, if you want interpolation, you need to set up a projection camera yourself? I ask because the setup for these two is very different, and (in the spirit of the plot window!) I'd like to try to reduce the complexity. If you're -1 on this, then we can keep it the way it is.
On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman@gmail.com<javascript:;>
wrote:
That capability doesn't exist yet for interpolated=True. When that is possible, I would be +1 with moving from volume to data_source.
On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk@gmail.com<javascript:;>
wrote:
On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman@gmail.com<javascript:;>
Hi all,
I think the only kwarg I'd be really +1 with getting rid of would be no_ghost. interpolated=True should just trigger no_ghost=False, and interpolated=False doesn't use the ghost zones no matter what. I
wrote: think
volume should stay, especially since I think it will soon be possible to do an off_axis_projection of a data object which would probably be fed in through the volume.
Why not get rid of volume and instead supply data_source, like projections?
Sam
On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk <matthewturk@gmail.com<javascript:;>
wrote:
Hi Elizabeth,
I agree, this makes sense.
Last night I tried to take a crack at this, but I got very confused with the various definitions of volume, interpolated, etc etc, in
the
routine off_axis_projection. Cameron and Sam, do you think it would be okay if we sim
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:;> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, I had figured we'd talk about this offline so as to not clutter everyone's mailboxes, but if you want to discuss it here, then I'm game.
To conduct an interpolated off-axis projection, we need to get the ghost-zone data. This data is relatively expensive to create, and so it makes sense to be able to keep it around for a good amount of time in between calculations -- for instance, if you want to spin around the orientation of the volume you're off-axis-projecting. So I understand wanting to keep either the kD-tree or the homogenized volume. This is generally an advanced operation, though. Creating a volume also allows for specifying a source. By creating a volume and specifying the source when doing so, you can get all of this behavior. And then, inside the ProjectionCamera, all of the operations for spinning the view around are exposed again. Previously, to change the viewing angle of an off-axis projection, the user had to create a volume manually, then repeatedly call off_axis_projection while resupplying the "volume" argument. Now, off_axis_projection is a thin wrapper of the ProjectionCamera. What do you mean "specify a source", because to me, that is the same as specifying an already-existing volume, but you're saying the two are different? Or does this come down to the difference between a KDtree/homogenized volume and an internal yt data volume like a sphere?
For non-interpolated off-axis projections, we don't need ghost zones. It's cheap to get out the grids. The parallelism strategy is completely different. And, we can also apply masks on the fly. In short, it's essentially a completely different operation in the backend. (And to keep them separate there are a bunch of conditionals inside ProjectionCamera.)
So where we need to direct our thoughts is on simplicity: we want to be able to provide a data_source, for two reasons: to get the field_parameters to pass through, and to allow cuts to be easily applied. I'm wondering if it is worth the substantial added complexity in API to supply *both* volume nad data_source to a wrapper function, when that wrapper function probably shouldn't even be used anymore if "volume" is a necessary argument.
In short: there's no reason to use off_axis_projection with a "volume" specified, since the use case that meets is met by the ProjectionCamera that off_axis_projection thinly wraps. So, can we just ditch that argument and replace it with a data_source? This kind of brings up the disjoint we have between "interpolated = True" and "interpolated = False" off_axis_projections, since to make them both work from within the same routine we've had to cram a whole bunch of conditionals and additional arguments into the same set of routines. If we add a data_source argument I just want to make sure we're not adding on an additional set of complexity where a simplification would be more appropriate.
So what you're saying is that you want to get rid of the interpolated behavior in off_axis_projections, like you wanted to do two weeks ago? Or you're just saying that the behavior will still exist if I manually create a homogenized volume/kdtree, then manually build a projectioncamera to take snapshots of it? If it is the second option, I guess that is fine, but I think we should make it clear how to go about doing this manually (in the docs) so that people don't flounder when trying to do anything more complex than what the very simple wrapper off_axis_projection will provide. I just don't want functionality to disappear, particularly when I'm still in the middle of using that functionality for a scientific paper that is about to be submitted (and may need further analysis/reproduction of interpolated off_axis_projections the way they have been historically been executed). To understand, are we trying to make all of the wrapper functions super simplistic, and leave more complex functionality for people willing to use the cameras directly? Cameron
-Matt
On Friday, June 29, 2012, Cameron Hummels wrote:
Hey guys,
I guess I don't entirely understand why these two functionalities are so different, but I'll chat with you, Matt, a bit more about this offline when I'm back at CU.
Cameron
> Okay. > > Cameron, I know you rely upon the off_axis_projection -- would it be > okay, in your opinion, if we deprecated the interpolated = True option > in some 2.X release and then in 3.0, if you want interpolation, you > need to set up a projection camera yourself? I ask because the setup > for these two is very different, and (in the spirit of the plot > window!) I'd like to try to reduce the complexity. If you're -1 on > this, then we can keep it the way it is. > > On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman@gmail.com <javascript:;>> > wrote: >> That capability doesn't exist yet for interpolated=True. When that is >> possible, I would be +1 with moving from volume to data_source. >> >> >> On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk@gmail.com <javascript:;>> >> wrote: >>> >>> On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman@gmail.com <javascript:;>> >>> wrote: >>> > Hi all, >>> > >>> > I think the only kwarg I'd be really +1 with getting rid of would be >>> > no_ghost. interpolated=True should just trigger no_ghost=False, and >>> > interpolated=False doesn't use the ghost zones no matter what. I >>> think >>> > volume should stay, especially since I think it will soon be possible >>> to >>> > do >>> > an off_axis_projection of a data object which would probably be fed >>> in >>> > through the volume. >>> >>> Why not get rid of volume and instead supply data_source, like >>> projections? >>> >>> > >>> > Sam >>> > >>> > >>> > On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk <matthewturk@gmail.com <javascript:;>> >>> > wrote: >>> >> >>> >> Hi Elizabeth, >>> >> >>> >> I agree, this makes sense. >>> >> >>> >> Last night I tried to take a crack at this, but I got very confused >>> >> with the various definitions of volume, interpolated, etc etc, in >>> the >>> >> routine off_axis_projection. Cameron and Sam, do you think it would >>> >> be okay if we sim
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:;> 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
-- Cameron Hummels PhD Candidate, Astronomy Department of Columbia University Public Outreach Director, Astronomy Department of Columbia University NASA IYA New York State Student Ambassador http://outreach.astro.columbia.edu PGP: 0x06F886E3
Sorry to chime in out of hand, but I think it would be nice to generate interpolated off-axis-projections with a keyword argument for the wrapper rather than going through the hassle of setting up the camera on my own. I think making it so hard to generate interpolated results has the net effect of blocking non-experts from ever doing it. Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum On Jul 2, 2012, at 4:36 PM, Cameron Hummels wrote:
Hi Matt,
I had figured we'd talk about this offline so as to not clutter everyone's mailboxes, but if you want to discuss it here, then I'm game.
To conduct an interpolated off-axis projection, we need to get the ghost-zone data. This data is relatively expensive to create, and so it makes sense to be able to keep it around for a good amount of time in between calculations -- for instance, if you want to spin around the orientation of the volume you're off-axis-projecting. So I understand wanting to keep either the kD-tree or the homogenized volume. This is generally an advanced operation, though. Creating a volume also allows for specifying a source. By creating a volume and specifying the source when doing so, you can get all of this behavior. And then, inside the ProjectionCamera, all of the operations for spinning the view around are exposed again. Previously, to change the viewing angle of an off-axis projection, the user had to create a volume manually, then repeatedly call off_axis_projection while resupplying the "volume" argument. Now, off_axis_projection is a thin wrapper of the ProjectionCamera.
What do you mean "specify a source", because to me, that is the same as specifying an already-existing volume, but you're saying the two are different? Or does this come down to the difference between a KDtree/homogenized volume and an internal yt data volume like a sphere?
For non-interpolated off-axis projections, we don't need ghost zones. It's cheap to get out the grids. The parallelism strategy is completely different. And, we can also apply masks on the fly. In short, it's essentially a completely different operation in the backend. (And to keep them separate there are a bunch of conditionals inside ProjectionCamera.)
So where we need to direct our thoughts is on simplicity: we want to be able to provide a data_source, for two reasons: to get the field_parameters to pass through, and to allow cuts to be easily applied. I'm wondering if it is worth the substantial added complexity in API to supply *both* volume nad data_source to a wrapper function, when that wrapper function probably shouldn't even be used anymore if "volume" is a necessary argument.
In short: there's no reason to use off_axis_projection with a "volume" specified, since the use case that meets is met by the ProjectionCamera that off_axis_projection thinly wraps. So, can we just ditch that argument and replace it with a data_source? This kind of brings up the disjoint we have between "interpolated = True" and "interpolated = False" off_axis_projections, since to make them both work from within the same routine we've had to cram a whole bunch of conditionals and additional arguments into the same set of routines. If we add a data_source argument I just want to make sure we're not adding on an additional set of complexity where a simplification would be more appropriate.
So what you're saying is that you want to get rid of the interpolated behavior in off_axis_projections, like you wanted to do two weeks ago? Or you're just saying that the behavior will still exist if I manually create a homogenized volume/kdtree, then manually build a projectioncamera to take snapshots of it? If it is the second option, I guess that is fine, but I think we should make it clear how to go about doing this manually (in the docs) so that people don't flounder when trying to do anything more complex than what the very simple wrapper off_axis_projection will provide.
I just don't want functionality to disappear, particularly when I'm still in the middle of using that functionality for a scientific paper that is about to be submitted (and may need further analysis/reproduction of interpolated off_axis_projections the way they have been historically been executed).
To understand, are we trying to make all of the wrapper functions super simplistic, and leave more complex functionality for people willing to use the cameras directly?
Cameron
-Matt
On Friday, June 29, 2012, Cameron Hummels wrote: Hey guys,
I guess I don't entirely understand why these two functionalities are so different, but I'll chat with you, Matt, a bit more about this offline when I'm back at CU.
Cameron
Okay.
Cameron, I know you rely upon the off_axis_projection -- would it be okay, in your opinion, if we deprecated the interpolated = True option in some 2.X release and then in 3.0, if you want interpolation, you need to set up a projection camera yourself? I ask because the setup for these two is very different, and (in the spirit of the plot window!) I'd like to try to reduce the complexity. If you're -1 on this, then we can keep it the way it is.
On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman@gmail.com> wrote:
That capability doesn't exist yet for interpolated=True. When that is possible, I would be +1 with moving from volume to data_source.
On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
I think the only kwarg I'd be really +1 with getting rid of would be no_ghost. interpolated=True should just trigger no_ghost=False, and interpolated=False doesn't use the ghost zones no matter what. I
On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <samskillman@gmail.com> wrote: think
volume should stay, especially since I think it will soon be possible to do an off_axis_projection of a data object which would probably be fed in through the volume.
Why not get rid of volume and instead supply data_source, like projections?
Sam
On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk <matthewturk@gmail.com> wrote: > > Hi Elizabeth, > > I agree, this makes sense. > > Last night I tried to take a crack at this, but I got very confused > with the various definitions of volume, interpolated, etc etc, in
the
> routine off_axis_projection. Cameron and Sam, do you think it would > be okay if we sim
_______________________________________________ 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
-- Cameron Hummels PhD Candidate, Astronomy Department of Columbia University Public Outreach Director, Astronomy Department of Columbia University NASA IYA New York State Student Ambassador http://outreach.astro.columbia.edu PGP: 0x06F886E3 !DSPAM:10175,4ff22eca2862958793331! _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4ff22eca2862958793331!
Hi Cameron, On Jul 2, 2012 7:29 PM, "Cameron Hummels" <chummels@astro.columbia.edu> wrote:
Hi Matt,
I had figured we'd talk about this offline so as to not clutter
To conduct an interpolated off-axis projection, we need to get the
ghost-zone data. This data is relatively expensive to create, and so it makes sense to be able to keep it around for a good amount of time in between calculations -- for instance, if you want to spin around the orientation of the volume you're off-axis-projecting. So I understand wanting to keep either the kD-tree or the homogenized volume. This is generally an advanced operation, though. Creating a volume also allows for specifying a source. By creating a volume and specifying the source when doing so, you can get all of this behavior. And then, inside the ProjectionCamera, all of the operations for spinning the view around are exposed again. Previously, to change the viewing angle of an off-axis
everyone's mailboxes, but if you want to discuss it here, then I'm game. projection, the user had to create a volume manually, then repeatedly call off_axis_projection while resupplying the "volume" argument. Now, off_axis_projection is a thin wrapper of the ProjectionCamera.
What do you mean "specify a source", because to me, that is the same as
specifying an already-existing volume, but you're saying the two are different? Or does this come down to the difference between a KDtree/homogenized volume and an internal yt data volume like a sphere? A source in this case is the second - an AMR3DData subclass just like is specified for profiles, axis-aligned projections, etc. These objects are a bit more flexible and can also carry field parameters more easily. I guess it would have been more clear for me to say: the question is really about specifying a volume vs specifying a data source. These are different because one is retained, the other not, and it's not at all about removing functionality.
For non-interpolated off-axis projections, we don't need ghost zones.
So where we need to direct our thoughts is on simplicity: we want to be
able to provide a data_source, for two reasons: to get the field_parameters to pass through, and to allow cuts to be easily applied. I'm wondering if it is worth the substantial added complexity in API to supply *both* volume nad data_source to a wrapper function, when that wrapper function probably shouldn't even be used anymore if "volume" is a necessary argument.
In short: there's no reason to use off_axis_projection with a "volume"
specified, since the use case that meets is met by the ProjectionCamera
It's cheap to get out the grids. The parallelism strategy is completely different. And, we can also apply masks on the fly. In short, it's essentially a completely different operation in the backend. (And to keep them separate there are a bunch of conditionals inside ProjectionCamera.) that off_axis_projection thinly wraps. So, can we just ditch that argument and replace it with a data_source? This kind of brings up the disjoint we have between "interpolated = True" and "interpolated = False" off_axis_projections, since to make them both work from within the same routine we've had to cram a whole bunch of conditionals and additional arguments into the same set of routines. If we add a data_source argument I just want to make sure we're not adding on an additional set of complexity where a simplification would be more appropriate.
So what you're saying is that you want to get rid of the interpolated
Or you're just saying that the behavior will still exist if I manually create a homogenized volume/kdtree, then manually build a projectioncamera to take snapshots of it? If it is the second option, I guess that is fine, but I think we should make it clear how to go about doing this manually (in the docs) so that
behavior in off_axis_projections, like you wanted to do two weeks ago? No, not at all. I just think we should choose between data sources, which are evaluated on the fly and volumes which are deliberately constructed and held in memory persistently. This is also only about the wrapper, not about any underlying code. Let me be perfectly clear when I say that our discussion (and the sentiment about removing functionality) two weeks ago about this has not been lost from my memory. people don't flounder when trying to do anything more complex than what the very simple wrapper off_axis_projection will provide.
I just don't want functionality to disappear, particularly when I'm still
in the middle of using that functionality for a scientific paper that is about to be submitted (and may need further analysis/reproduction of interpolated off_axis_projections the way they have been historically been executed). 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.
To understand, are we trying to make all of the wrapper functions super
simplistic, and leave more complex functionality for people willing to use the cameras directly? That is in general my preference, but I understand that I may not be in the majority, and I understand it may not be right for every case. My original thought was we'd get rid of the volume= kwarg, which would mean that for the use case of repeatedly calling off_axis_projection (which is not stateful) you'd instead need to set up a (stateful) Camera object, which can be rotated, zoomed, etc. This would mean that the only difference for a workflow would be to using the camera rather than the routine. However, the reason I brought it up -- and wanted to discuss this where others (like Nathan) can chime in -- is because it's important when doing this kind of thing that input gets solicited so that users are neither abandoned nor left out on a limb. Maybe a better option is to leave the off_axis_projection alone, and either not support data_sources & field_parameters, or move the entire non-interpolated code into a separate routine, where those items *can* be included. Would that work for you? -Matt
Cameron
-Matt
On Friday, June 29, 2012, Cameron Hummels wrote:
Hey guys,
I guess I don't entirely understand why these two functionalities are so different, but I'll chat with you, Matt, a bit more about this offline when I'm back at CU.
Cameron
Okay.
Cameron, I know you rely upon the off_axis_projection -- would it be okay, in your opinion, if we deprecated the interpolated = True option in some 2.X release and then in 3.0, if you want interpolation, you need to set up a projection camera yourself? I ask because the setup for these two is very different, and (in the spirit of the plot window!) I'd like to try to reduce the complexity. If you're -1 on this, then we can keep it the way it is.
On Thu, Jun 28, 2012 at 11:57 AM, Sam Skillman <samskillman@gmail.com> wrote:
That capability doesn't exist yet for interpolated=True. When that is possible, I would be +1 with moving from volume to data_source.
On Thu, Jun 28, 2012 at 9:53 AM, Matthew Turk <matthewturk@gmail.com> wrote:
On Thu, Jun 28, 2012 at 11:51 AM, Sam Skillman <
wrote: > Hi all, > > I think the only kwarg I'd be really +1 with getting rid of would be > no_ghost. interpolated=True should just trigger no_ghost=False, and > interpolated=False doesn't use the ghost zones no matter what. I think > volume should stay, especially since I think it will soon be
samskillman@gmail.com> possible
to > do > an off_axis_projection of a data object which would probably be fed in > through the volume.
Why not get rid of volume and instead supply data_source, like projections?
> > Sam > > > On Thu, Jun 28, 2012 at 9:39 AM, Matthew Turk < matthewturk@gmail.com> > wrote: >> >> Hi Elizabeth, >> >> I agree, this makes sense. >> >> Last night I tried to take a crack at this, but I got very confused >> with the various definitions of volume, interpolated, etc etc, in the >> routine off_axis_projection. Cameron and Sam, do you think it would >> be okay if we sim
_______________________________________________ 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
-- Cameron Hummels PhD Candidate, Astronomy Department of Columbia University Public Outreach Director, Astronomy Department of Columbia University NASA IYA New York State Student Ambassador http://outreach.astro.columbia.edu PGP: 0x06F886E3
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4ff240027592279525482!
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 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. Sam On Mon, Jul 2, 2012 at 6:47 PM, Nathan Goldbaum <goldbaum@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@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@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
Hey Sam, On Tue, Jul 3, 2012 at 12:58 PM, Sam Skillman <samskillman@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@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@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@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
Hi, On Tue, Jul 3, 2012 at 11:01 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hey Sam,
On Tue, Jul 3, 2012 at 12:58 PM, Sam Skillman <samskillman@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@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
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
participants (4)
-
Cameron Hummels -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman