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.
Not a known issues. Please share data and a state file if possible.
Thanks for your reply. Unfortunately I can’t share the date showed in the picture.
If I have time i’ll try to reproduce this behavior with a smaller data set that I can share.
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)
I uploaded the case (more or less a (decomposed) OpenFOAM structure) here. It is also a state included. I did use ParaView 5.9.0 in server/client (osmesa) with 60 cores.
Let me know what’s going on
Unable to reproduce in client/server with 2 cores with ParaView 5.9.1.
Could you try on your side ?
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’d first need to be able to reproduce the issue. Let me know if you find a setup to reproduce the issue with 8 pvserver max.
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.
Let me know if this works for you.
state_streamlines.pvsm (2.6 MB)
@timothee.chabat : I believe you fixed that, right ?
Yes it should be fixed on ParaView master. I don’t think it will be available on ParaView 5.10 though, maybe in 5.10.1.
Was an issue created based on my post? Is there a link to the issue tracking where I can find some deteails what happened?
Thank you very much!
Yes of course, my bad for not linking them ! It was actually not based on your post but here are the links :
Pardon my ignorance, how can I check if the fix made it into a release?
I’m wondering if this is fixed in v5.10.1
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
There is two ways to know if something is in the release.
- Check the release notes.
While not exhaustive, the release notes contains many information:
- Check the git repoistory
If you know which file has been fixed, you can check in the git repository.
Using both techniques shows that this fix is not present in 5.10.1.
As @timothee.chabat remarked, this fix will be present in 5.11.