I’ve run into some odd behavior with the glyph filter. When generating glyphs at all points, it seems to occasionally stick the arrows in the wrong spot. E.g., here’s a picture showing what I expect to see:
If I fiddle with the scaling of the glyphs and reapply (so that it regenerates the glyphs), occasionally it’ll wind up putting arrows off in empty space (and having them missing in some cells):
I’ve circled the incorrect arrows and the cells that are missing arrows.
The problem seems to occur with all points, every nth point (though less common because of fewer points), and with uniform distribution (bounds and volume), but uniform surface sampling seems immune.
The issue does not appear to be deterministic. Going back and forth with different scalings, sometimes it’ll work right, sometimes it’ll break, and it doesn’t produce the same glyphs for any given values of the settings.
Attached is a file that suffices to show the issue. Steps to reproduce:
- Start ParaView and load the file.
- Set style to surface with edges and reduce opacity to around 0.2 so that you can see the glyphs.
- Add a glyph filter.
- Set the orientation array to current_sc.
- No scale array, set the scaling to 5.
- Set glyph mode to all points.
- Apply to generate the glyphs and see if it breaks.
- If not, change the scaling to 4 and re-apply.
- Repeat a few times until you notice some extraneous glyphs that are not part of the geometry.
Anyone seen this issue or have suggestions for how to avoid it? Right now I’m doing a try:except: to see if surface sampling is available, but I’d like to have all points available to the user if they desire it.
glyphbug.vtu (23.2 KB)
There is point duplication issues in your dataset.
Not sure why this provoques this bug, but using “Clean To Grid” filter seems to correct it.
I’d never have guessed that was the issue, but thanks for pointing out a way around the problem. I’ll fix the generation program to clean up the coordinates before the initial VTU file is produced.
I cleaned up the point duplication, but discovered that’s not the underlying issue; it’s something that’s being triggered by Int32 vs Int64 in the offsets and connectivity arrays. Attached are a couple of files, cleaned.vtu, where I’ve saved the output from the clean filter directly. This seems to have no issues. The second file, cleaned32.vtu, is where I’ve manually changed the two Int64’s in cleaned.vtu to Int32. The file data is ASCII-encoded, so you can easily see that that’s the only difference. The Int32 version has the problem though. Reproduction steps:
- Open cleaned32.vtu and apply
- Select current and surface with edges, reduce opacity to 0.2
- Filters->Glyph, select orientation array current_dir, no scale array, scale factor 5, all points, apply
- If need be, switch back and forth between scale factor 4 + apply and scale factor 5 + apply a few times. At some point you’ll see the misplaced arrows.
Repeating the same steps with cleaned.vtu (having Int64 instead of Int32) never shows the issue. FWIW, I’m running the 64-bit ParaView on 64-bit Linux.
cleaned.vtu (1.1 MB)
cleaned32.vtu (1.1 MB)
Right ! That may be related to the recent changes to the cells structures. See here :
Which version of ParaView are you using ?
ParaView-5.8.0-MPI-Linux-Python3.7-64bit, which I downloaded as the Linux release from paraview.org
Can you try with the nightly of ParaView ?
Is there a complete download for the nightly? I find ParaView-latest-osmesa-MPI-Linux-Python3.7-64bit.tar.gz which says it doesn’t include the GUI. Or is there a way to point the GUI I have from 5.8.0 to the nightly backend part?
The issue is still there in the nightly.
Thanks for your report. This would require more investigation.
You may want to open an issue on our gitlab : https://gitlab.kitware.com/paraview/paraview/-/issues
For posterity, this issue was resolved in ParaView 5.8.1.