I heavily rely on the filter “Stream Tracer With Custom Source” and have been using it for a while now. However there seems to be an annoying bug with the seeding. I use the “Mask Points” filter for the seeding. If there are multiple stream tracer with custom source in the pipeline on the same dataset but with different seedings, ParaView seems to be confused. For one stream tracer the streamlines starts to seed from the other (hidden) stream tracer.
In the attached picture is an example. The stream tracer 2 uses the black dots as seeding. But there are some streamlines generated from the seeding of stream tracer 1. If I play with the settings (e.g. max. streamline length, vectors), the behavior changes and sometimes i manage to make it look right but then the streamlines are too short etc.
I’m using ParaView v5.7.0 in parallel (server/client, osmesa). I don’t know if this behavior is the same with newer versions. I would have to upgrade the server. If somebody could confirm this is known and solved in later releases, i would upgrade.
The behavior is totally reproducible. I made a smaller example i can share. Also I updated to v.5.9.0 but nothing changed.
It happens if multiple StreamTracerWithCustomSource are present in the pipeline. The first few stream tracers are fine then suddenly the weird behavior appears not only on the newly added stream tracers: (picture with just one stream tracer visible)
Updating the server to 5.9.1 is currently not possible. I tried using only 2 cores as you did and it also did not reproduce the behavior.
I noticed the StreamTracerWithCustomSource works a lot better if the dataset is reconstructed. I was using the built-in OpenFOAM reader and my data was still decomposed. I find the option to load a decomposed case very nice but it seems to cause problems.
Reconstructing the case and load the reconstructed case with 60 cores seems to fix the problems. Also no crashes anymore. Before I had frequent crashes with the StreamTracerWithCustomSource filter.
Is there any chance to find out what’s wrong with the decomposed reader?
I’m afraid I can’t give you a state file that will show you the behavior right away. However I’m sure you can provoke it on your side:
Start 8 pvservers, load the attached state file (uses the data from previous post). The state has just one StreamTracerWithCustomSource filter and it will probably load without problems. Keep adding more StreamTracerWithCustomSource filters to the pipeline by using the MaskPoints2…8 as seeding elements. At some point you will notice streamlines which are broken/interrupted, the previously shown wrong seeding location or what always happens on my side at some point: ParaView will crash even there is plenty of memory left on both sides, server and client.
Well you can test it by hand but there is no easy way of knowing if a fix has been backported to the release branch afaik. Although you can check the MR and see if it has been mentioned in another MR, but this is not the case here (although it may have been forgotten).
[EDIT] ParaView 5.11 should be out in around 2 months if you want
