[yt-dev] Particle-Only Plots

[Nathan Goldbaum]

On Thu, Aug 28, 2014 at 11:52 AM, Andrew Myers <atmyers2 at 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 at 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 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/20140828/a8982dc2/attachment.html>