[Paraview-developers] [Paraview] Accessing particles generated by ParticleTracer

[Mathieu Westphal]

Hello

Regarding the Programmable Filter, you are right, there is no way to
specify it upstream,
 you would need to keep a list of previously deleted particle that should
stay deleted, definitelly not a great solution.

Regarding the inheritance, you are right as well, but keep in mind that
ParaView is Open Source and you can contribute to the code of the
vtkParticleStreamer if you want
and add some kind of check in the base class that you could redefine in
your class if you want.

Regarding the plugin loading problem, are you trying to load the plugin in
the paraview release (not good) or in the paraview you build the plugin
with (good).
If this part is ok, then i would suggest first trying the examples plugins
in ParaView source. You will find correctly written CMakeLists and you can
work your way up from there.
"paraview/Examples/Plugins/Filter" seems a good starting point. Just copy
the folder somewhere, build it and check it can be loaded in ParaView.

Let me know if you run into any troubles.

Best,


Mathieu Westphal

On Wed, Oct 18, 2017 at 6:30 PM, Van Moer, Mark W <mvanmoer at illinois.edu>
wrote:

> Hi Mathieu,
>
>
>
> Thanks for the suggestions. I tried having a Programmable Filter take the
> PolyData input, do the check, and write new PolyData output, and that kind
> of worked, except that particles could reappear after being deleted. That a
> particle was deleted wasn’t being sent back upstream to the Particle
> Tracer, upstream state changes aren’t supported as I understand it.
>
>
>
> I tried making a plugin by deriving from vtkParticleTracerBase and
> overriding RequestData() and IntegrateParticles(), however, that doesn’t
> work because they accesses private members of vtkParticleTracerBase.
>
>
>
> I also tried copying vtkParticleTracerBase to a new class and hacking on
> it directly, but I’m getting link errors when I try to load the plugin,
> like
>
>
>
> undefined symbol: _*Z34vtkParticleTracerWithSinkBase_Init*_
> P26vtkClientServerInterpreter
>
>
>
> (I was able to hack directly on vtkParticleTracerBase.cxx in the ParaView
> src tree and it worked as expected, but I would rather get a plugin
> working.)
>
>
>
> -          When making a plugin based on an abstract VTK class, does
> something need to change in the CMakeLists.txt? I’m just guessing that’s
> where my issue with the link error is?
>
>
>
> Thanks,
>
> Mark
>
>
>
>
>
>
>
> *From:* Mathieu Westphal [mailto:mathieu.westphal at kitware.com]
> *Sent:* Tuesday, September 26, 2017 9:22 AM
> *To:* Van Moer, Mark W <mvanmoer at illinois.edu>
> *Cc:* ParaView Developers <paraview-developers at paraview.org>; ParaView <
> paraview at paraview.org>
>
> *Subject:* Re: [Paraview] Accessing particles generated by ParticleTracer
>
>
>
> Hello
>
> Simplest way to go would be to add a Python Programmable Filter after the
> particle tracer, that process each point and does not copy it when it is
> too far from an arbitrary point.
>
> This would work, even with paraview release, but will not be so most
> efficient implementation.
>
> Harder way to go would be to copy(or inherit) the ParticleTracer as a new
> vtk filter and associated xml proxy plugin. And add a radius check in the
> code, probably in vtkParticleTracerBase::RequestData:1188
>
>             // if the particle is sent, remove it from the list
> -            if (this->SendParticleToAnotherProcess(info,previous,this->
> OutputPointData))
>
> +            if (this->SendParticleToAnotherProcess(info,previous,this->OutputPointData)
> || !yourRadiusTest(point2))
>
>             {
>               this->ParticleHistories.erase(it);
>               particle_good = false;
>
>              }
>
>
>
> much more efficient but you will need to know C++ and how to compile
> ParaView and a ParaView plugin.
>
>
>
> Best,
>
>
> Mathieu Westphal
>
>
>
> On Tue, Sep 26, 2017 at 3:53 PM, Van Moer, Mark W <mvanmoer at illinois.edu>
> wrote:
>
> Hi Mathieu,
>
>
>
> The full science context is, this is a simulation of a binary black hole
> system. The way the solver works, the black hole locations aren’t actually
> in the mesh, they’re stored as separate coordinates with an associated
> radius. The black holes orbit each other during the simulation, creating
> turbulence in the plasma (and magnetic field). I made a few videos of
> particles being advected by the plasma velocity. This was basically just
> the mesh, a seed source, and a Particle Tracer filter. This works fine,
> except that particles which get within the radius of each black hole end up
> coagulating and behaving non-physically. If I understand the scientist
> right, in the simulation itself, they are able to handle this somehow
> correctly, but that behavior doesn’t get translated to what’s saved in the
> mesh.
>
>
>
> That’s part 1. Part 2 of the vis, and this works, is that the plasma
> advected particles are used as seeds for streamlines through the magnetic
> field -- though there are streamlines coming out of non-physically correct
> particles.
>
>
>
> What I’d like is to be able to check of each of the actual particle
> locations vs the black hole locations and radii and if they’re within that
> radii, delete them (or hide them, make them transparent, whatever.)  I was
> hoping this was something I could do with a programmable filter, but I’m
> open to any suggestions, including hacking on VTK source.
>
>
>
> Mark
>
>
>
> *From:* Mathieu Westphal [mailto:mathieu.westphal at kitware.com]
> *Sent:* Tuesday, September 26, 2017 2:47 AM
> *To:* Van Moer, Mark W <mvanmoer at illinois.edu>; ParaView Developers <
> paraview-developers at paraview.org>
> *Cc:* ParaView <paraview at paraview.org>
> *Subject:* Re: [Paraview] Accessing particles generated by ParticleTracer
>
>
>
> Hello
>
> Can you give some context ? At which level of implementation are you
> trying to do that ?
>
> Best,
>
>
> Mathieu Westphal
>
>
>
> On Tue, Sep 26, 2017 at 12:09 AM, Van Moer, Mark W <mvanmoer at illinois.edu>
> wrote:
>
> Looks like I’d have to get at the std::vector<ParticleInformation>
> ParticleVector that’s inherited from vtkParticleTracerBase? I’m guessing
> that’s not exposed by the proxy.
>
> Mark
>
>
>
> *From:* Van Moer, Mark W
> *Sent:* Monday, September 25, 2017 2:25 PM
> *To:* ParaView <paraview at paraview.org>
> *Subject:* Accessing particles generated by ParticleTracer
>
>
>
> Hi ParaView,
>
>
>
> Is it possible to get at the individual particles generated by
> ParticleTracer? I’ve been handed a mesh with a velocity field and an
> implied particle sink. I’d like to delete any particles that wander within
> a certain radius of that sink. My thought was if I could get at the array
> holding the particles I could check each distance and delete as necessary.
>
>
>
> Thanks,
>
> Mark
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171019/c847a438/attachment.html>