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