Particle-Only Plots
Hi folks,
A while back, Jeremy Ritter asked the yt-users list if yt could produce a particle plot like that obtained through annotate_particles(), but without loading any mesh data. The answer was "no", but that it isn't too hard to use matplotlib directly. Personally, this is a visualization task that I do all the time, and I think it would be useful to make this type of plot a one-liner in yt - provided it handles units and labels and such automatically like any other yt plot.
I've added this feature in my fork of yt. The interface is the same as for any other yt plots, and the standard plot modification mechanisms should work. Examples are here http://nbviewer.ipython.org/gist/atmyers/f8616c9ed5a9d2b027e8 and here http://nbviewer.ipython.org/gist/atmyers/8d979d990268f48c9688.
If there is interest in having this in mainline yt I'll write some docs and issue a pull request.
-Andrew
Hi Andrew,
This is a really great idea and something that should be a big usability win as more and more people use yt with particle datasets. I have several comments, questions, and suggestions but overall an emphatic +1 on this eventually making its way into yt.
Is ParticlePlot a subclass of PlotContainer? Does it make sense to do that? For all the other plotting classes there is a sense of a list of fields to loop over and store plots for per-object. Your plotting class could accept a list of x and y fields (does it?) so I guess you could store all permutations of x and y field combinations and make a plot for each one, although I'm not sure if that makes sense.
Should we perhaps instead have a class that splats particle positions onto spatial axes and another that does the same for arbitrary combinations of fields like ProfilePlot and PhasePlot? One issue with your second example is that the aspect ratio isn't equal for both axes, which is presumably why your spherical distribution of particles appears a bit squashed. It would be straightforward to handle this if we know the x and y axes are spatial, less so if the plotting class has to handle axes with generic dimensions.
I'd prefer it if we could keep the plotting code as unified as possible. Optimally, this means that individual plots should subclass PlotMPL and ParticlePlot would subclass PlotContainer. Doing so should reduce code duplication and also ease maintainability going forward. That said, I totally understand that you have the code written already and don't want to force you to rewrite a bunch of stuff you've alrady written. One bonus of using the plotting infrastructure that's in yt right now is that you should be able to wire up the PlotWindow plot callbacks, at least for plots that have spatial fields along both axes.
It might be useful to hash this out in a YTEP.
Hope that's not too much feedback - if you can't tell i'm excited about this!
-Nathan
On Wed, Aug 27, 2014 at 11:26 PM, Andrew Myers atmyers2@gmail.com wrote:
Hi folks,
A while back, Jeremy Ritter asked the yt-users list if yt could produce a particle plot like that obtained through annotate_particles(), but without loading any mesh data. The answer was "no", but that it isn't too hard to use matplotlib directly. Personally, this is a visualization task that I do all the time, and I think it would be useful to make this type of plot a one-liner in yt - provided it handles units and labels and such automatically like any other yt plot.
I've added this feature in my fork of yt. The interface is the same as for any other yt plots, and the standard plot modification mechanisms should work. Examples are here http://nbviewer.ipython.org/gist/atmyers/f8616c9ed5a9d2b027e8 and here http://nbviewer.ipython.org/gist/atmyers/8d979d990268f48c9688.
If there is interest in having this in mainline yt I'll write some docs and issue a pull request.
-Andrew
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Thu, Aug 28, 2014 at 1:48 AM, Nathan Goldbaum nathan12343@gmail.com wrote:
Hi Andrew,
This is a really great idea and something that should be a big usability win as more and more people use yt with particle datasets. I have several comments, questions, and suggestions but overall an emphatic +1 on this eventually making its way into yt.
Is ParticlePlot a subclass of PlotContainer? Does it make sense to do that? For all the other plotting classes there is a sense of a list of fields to loop over and store plots for per-object. Your plotting class could accept a list of x and y fields (does it?) so I guess you could store all permutations of x and y field combinations and make a plot for each one, although I'm not sure if that makes sense.
Should we perhaps instead have a class that splats particle positions onto spatial axes and another that does the same for arbitrary combinations of fields like ProfilePlot and PhasePlot? One issue with your second example is that the aspect ratio isn't equal for both axes, which is presumably why your spherical distribution of particles appears a bit squashed. It would be straightforward to handle this if we know the x and y axes are spatial, less so if the plotting class has to handle axes with generic dimensions.
I'm generally +10 on Andrew's idea; one thing I want to note is that the speed of Matplotlib's point plotting can go down quite quickly with the number of points. A splatting routine (which I think Sam has put into a PR?) would speed it up, and if the splat size were less than the pixel size for the plot, it should be indistinguishable.
I'd prefer it if we could keep the plotting code as unified as possible. Optimally, this means that individual plots should subclass PlotMPL and ParticlePlot would subclass PlotContainer. Doing so should reduce code duplication and also ease maintainability going forward. That said, I totally understand that you have the code written already and don't want to force you to rewrite a bunch of stuff you've alrady written. One bonus of using the plotting infrastructure that's in yt right now is that you should be able to wire up the PlotWindow plot callbacks, at least for plots that have spatial fields along both axes.
It might be useful to hash this out in a YTEP.
Hope that's not too much feedback - if you can't tell i'm excited about this!
-Nathan
On Wed, Aug 27, 2014 at 11:26 PM, Andrew Myers atmyers2@gmail.com wrote:
Hi folks,
A while back, Jeremy Ritter asked the yt-users list if yt could produce a particle plot like that obtained through annotate_particles(), but without loading any mesh data. The answer was "no", but that it isn't too hard to use matplotlib directly. Personally, this is a visualization task that I do all the time, and I think it would be useful to make this type of plot a one-liner in yt - provided it handles units and labels and such automatically like any other yt plot.
I've added this feature in my fork of yt. The interface is the same as for any other yt plots, and the standard plot modification mechanisms should work. Examples are here and here.
If there is interest in having this in mainline yt I'll write some docs and issue a pull request.
-Andrew
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 Nathan,
Is ParticlePlot a subclass of PlotContainer? Does it make sense to do that?
Currently, no, but I think I agree that it should do so. The reason I didn't do this in the first place was that I was referencing ProfilePlot, which doesn't inherit from PlotContainer. (I don't see a generic PlotContainer class, just an ImagePlotContainer for plots with colorbars). I think the functionality that is common to ParticlePlot and ProfilePlot should be put into a base class analogous to ImagePlotContainer but without the colorbar stuff. Or maybe have a generic PlotContainer, from which ImagePlotContainer inherits, and which ProfilePlot and ParticlePlot subclass directly?
For all the other plotting classes there is a sense of a list of fields to loop over and store plots for per-object. Your plotting class could accept a list of x and y fields (does it?) so I guess you could store all permutations of x and y field combinations and make a plot for each one, although I'm not sure if that makes sense.
Again, no, but for the sake of consistency I think it you're right that it should do so. All permutations may be overkill, though. Maybe if you pass in [x1, x2, x3] and [y1, y2, y3] it should store [x1 vs. y1, x2 vs y2, x3 vs y3] and so forth.
Should we perhaps instead have a class that splats particle positions onto spatial axes and another that does the same for arbitrary combinations of fields like ProfilePlot and PhasePlot? One issue with your second example is that the aspect ratio isn't equal for both axes, which is presumably why your spherical distribution of particles appears a bit squashed. It would be straightforward to handle this if we know the x and y axes are spatial, less so if the plotting class has to handle axes with generic dimensions.
I'd prefer it if we could keep the plotting code as unified as possible. Optimally, this means that individual plots should subclass PlotMPL and ParticlePlot would subclass PlotContainer. Doing so should reduce code duplication and also ease maintainability going forward. That said, I totally understand that you have the code written already and don't want to force you to rewrite a bunch of stuff you've alrady written. One bonus of using the plotting infrastructure that's in yt right now is that you should be able to wire up the PlotWindow plot callbacks, at least for plots that have spatial fields along both axes.
It might be useful to hash this out in a YTEP.
I think I agree, since we are talking about refactoring existing plotting code. I'll write something up and submit it.
Thanks for the detailed comments - I'm happy to do the extra work to do this properly.
Hope that's not too much feedback - if you can't tell i'm excited about this!
-Nathan
On Wed, Aug 27, 2014 at 11:26 PM, Andrew Myers atmyers2@gmail.com wrote:
Hi folks,
A while back, Jeremy Ritter asked the yt-users list if yt could produce a particle plot like that obtained through annotate_particles(), but without loading any mesh data. The answer was "no", but that it isn't too hard to use matplotlib directly. Personally, this is a visualization task that I do all the time, and I think it would be useful to make this type of plot a one-liner in yt - provided it handles units and labels and such automatically like any other yt plot.
I've added this feature in my fork of yt. The interface is the same as for any other yt plots, and the standard plot modification mechanisms should work. Examples are here http://nbviewer.ipython.org/gist/atmyers/f8616c9ed5a9d2b027e8 and here http://nbviewer.ipython.org/gist/atmyers/8d979d990268f48c9688.
If there is interest in having this in mainline yt I'll write some docs and issue a pull request.
-Andrew
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 Matt,
Could you point me this PR? I'm having some trouble finding it.
Thanks, Andrew
On Thu, Aug 28, 2014 at 4:47 AM, Matthew Turk matthewturk@gmail.com wrote:
On Thu, Aug 28, 2014 at 1:48 AM, Nathan Goldbaum nathan12343@gmail.com wrote:
Hi Andrew,
This is a really great idea and something that should be a big usability
win
as more and more people use yt with particle datasets. I have several comments, questions, and suggestions but overall an emphatic +1 on this eventually making its way into yt.
Is ParticlePlot a subclass of PlotContainer? Does it make sense to do
that?
For all the other plotting classes there is a sense of a list of fields
to
loop over and store plots for per-object. Your plotting class could
accept a
list of x and y fields (does it?) so I guess you could store all permutations of x and y field combinations and make a plot for each one, although I'm not sure if that makes sense.
Should we perhaps instead have a class that splats particle positions
onto
spatial axes and another that does the same for arbitrary combinations of fields like ProfilePlot and PhasePlot? One issue with your second
example
is that the aspect ratio isn't equal for both axes, which is presumably
why
your spherical distribution of particles appears a bit squashed. It
would
be straightforward to handle this if we know the x and y axes are
spatial,
less so if the plotting class has to handle axes with generic dimensions.
I'm generally +10 on Andrew's idea; one thing I want to note is that the speed of Matplotlib's point plotting can go down quite quickly with the number of points. A splatting routine (which I think Sam has put into a PR?) would speed it up, and if the splat size were less than the pixel size for the plot, it should be indistinguishable.
I'd prefer it if we could keep the plotting code as unified as possible. Optimally, this means that individual plots should subclass PlotMPL and ParticlePlot would subclass PlotContainer. Doing so should reduce code duplication and also ease maintainability going forward. That said, I totally understand that you have the code written already and don't want
to
force you to rewrite a bunch of stuff you've alrady written. One bonus
of
using the plotting infrastructure that's in yt right now is that you
should
be able to wire up the PlotWindow plot callbacks, at least for plots that have spatial fields along both axes.
It might be useful to hash this out in a YTEP.
Hope that's not too much feedback - if you can't tell i'm excited about this!
-Nathan
On Wed, Aug 27, 2014 at 11:26 PM, Andrew Myers atmyers2@gmail.com
wrote:
Hi folks,
A while back, Jeremy Ritter asked the yt-users list if yt could produce
a
particle plot like that obtained through annotate_particles(), but
without
loading any mesh data. The answer was "no", but that it isn't too hard
to
use matplotlib directly. Personally, this is a visualization task that
I do
all the time, and I think it would be useful to make this type of plot a one-liner in yt - provided it handles units and labels and such automatically like any other yt plot.
I've added this feature in my fork of yt. The interface is the same as
for
any other yt plots, and the standard plot modification mechanisms should work. Examples are here and here.
If there is interest in having this in mainline yt I'll write some docs and issue a pull request.
-Andrew
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
On Thu, Aug 28, 2014 at 11:52 AM, Andrew Myers atmyers2@gmail.com wrote:
Hi Nathan,
Is ParticlePlot a subclass of PlotContainer? Does it make sense to do that?
Currently, no, but I think I agree that it should do so. The reason I didn't do this in the first place was that I was referencing ProfilePlot, which doesn't inherit from PlotContainer. (I don't see a generic PlotContainer class, just an ImagePlotContainer for plots with colorbars). I think the functionality that is common to ParticlePlot and ProfilePlot should be put into a base class analogous to ImagePlotContainer but without the colorbar stuff. Or maybe have a generic PlotContainer, from which ImagePlotContainer inherits, and which ProfilePlot and ParticlePlot subclass directly?
There already is a PlotContainer. Take a look in yt/visualization/plot_container.py. ImagePlotContainer is also in there - it inherits from PlotContainer.
ProfilePlot doesn't inherit from PlotContainer for historical reasons (Matt wrote most of the infrastructure before PlotContainer existed). That said, it has some slightly different semantics compared to the other plotting classes, since you can overplot many profiles on the same plot.
I'd prefer if new plotting classes could inherit from it.
For all the other plotting classes there is a sense of a list of fields to loop over and store plots for per-object. Your plotting class could accept a list of x and y fields (does it?) so I guess you could store all permutations of x and y field combinations and make a plot for each one, although I'm not sure if that makes sense.
Again, no, but for the sake of consistency I think it you're right that it should do so. All permutations may be overkill, though. Maybe if you pass in [x1, x2, x3] and [y1, y2, y3] it should store [x1 vs. y1, x2 vs y2, x3 vs y3] and so forth.
So long as there's logic to enforce that API, that's fine with me.
Should we perhaps instead have a class that splats particle positions onto spatial axes and another that does the same for arbitrary combinations of fields like ProfilePlot and PhasePlot? One issue with your second example is that the aspect ratio isn't equal for both axes, which is presumably why your spherical distribution of particles appears a bit squashed. It would be straightforward to handle this if we know the x and y axes are spatial, less so if the plotting class has to handle axes with generic dimensions.
I'd prefer it if we could keep the plotting code as unified as possible. Optimally, this means that individual plots should subclass PlotMPL and ParticlePlot would subclass PlotContainer. Doing so should reduce code duplication and also ease maintainability going forward. That said, I totally understand that you have the code written already and don't want to force you to rewrite a bunch of stuff you've alrady written. One bonus of using the plotting infrastructure that's in yt right now is that you should be able to wire up the PlotWindow plot callbacks, at least for plots that have spatial fields along both axes.
It might be useful to hash this out in a YTEP.
I think I agree, since we are talking about refactoring existing plotting code. I'll write something up and submit it.
Thanks for the detailed comments - I'm happy to do the extra work to do this properly.
The (accepted) PR Matt was referring to is here: https://bitbucket.org/yt_analysis/yt/pull-request/887/color-splatting/diff
You might be able to use this to construct something analogous to the FixedResolutionBuffer.
Hope that's not too much feedback - if you can't tell i'm excited about this!
-Nathan
On Wed, Aug 27, 2014 at 11:26 PM, Andrew Myers atmyers2@gmail.com wrote:
Hi folks,
A while back, Jeremy Ritter asked the yt-users list if yt could produce a particle plot like that obtained through annotate_particles(), but without loading any mesh data. The answer was "no", but that it isn't too hard to use matplotlib directly. Personally, this is a visualization task that I do all the time, and I think it would be useful to make this type of plot a one-liner in yt - provided it handles units and labels and such automatically like any other yt plot.
I've added this feature in my fork of yt. The interface is the same as for any other yt plots, and the standard plot modification mechanisms should work. Examples are here http://nbviewer.ipython.org/gist/atmyers/f8616c9ed5a9d2b027e8 and here http://nbviewer.ipython.org/gist/atmyers/8d979d990268f48c9688.
If there is interest in having this in mainline yt I'll write some docs and issue a pull request.
-Andrew
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 (3)
-
Andrew Myers -
Matthew Turk -
Nathan Goldbaum