[Paraview] Accessing particles generated by ParticleTracer

[Van Moer, Mark W]

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<mailto: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<mailto:mathieu.westphal at kitware.com>]
Sent: Tuesday, September 26, 2017 2:47 AM
To: Van Moer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>>; ParaView Developers <paraview-developers at paraview.org<mailto:paraview-developers at paraview.org>>
Cc: ParaView <paraview at paraview.org<mailto: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<mailto: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<mailto: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<http://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/attachments/20171018/564d5d3a/attachment.html>