Slice filter performance in ParaView 5.13

ParaView Support
1

Hello all,

I’m using ParaView to post-process OpenFOAM simulations.
After moving from ParaView 5.11 to 5.13/5.13.1, I noticed a huge drop in performance for the slice filter.

Slicing a relatively small dataset (3 millions cells) in 5.11 took under 3 seconds, while the same slice in 5.13 takes 2min55…

I noticed changes in the slice filter in 5.13 (point merge method selection instead of the old “Merge duplicated points in the slice” option) but I cannot find a way to get faster slices.

I have the same behavior using the OpenFOAM and EnSight readers. (multi-block dataset with unstructured grid)

Is there a way to retrieve the old behavior and get back faster slicing?

Thanks,
Yann

2

Hello @Yann,

It might be related to this thread : Strange slice filter update behaviour - #6 by mwestphal

Maybe @spyridon97 have some inputs?

3

Thanks @Lucas_Givord for the insight.

Here is what I get in Timer log:

ParaView 5.11.0

Still Render,  0.036 seconds
    Render (use_lod: 0), (use_distributed_rendering: 0), (use_ordered_compositing: 0)
    OpenGL Dev Render,  0.033 seconds
PropertiesPanel::Apply,  2.663 seconds
    ParaViewPipelineControllerWithRendering::UpdatePipelineBeforeDisplay,  1.711 seconds
        Execute Slice1 id: 9807,  1.687 seconds
    ParaViewPipelineControllerWithRendering::Show,  0.881 seconds
        ParaViewPipelineControllerWithRendering::Show::CreatingRepresentation,  0.847 seconds
    Still Render,  0.05 seconds
        Render (use_lod: 0), (use_distributed_rendering: 0), (use_ordered_compositing: 0)
        OpenGL Dev Render,  0.012 seconds
        OpenGL Dev Render,  0.035 seconds

ParaView 5.13.1

Still Render,  0.067 seconds
    Render (use_lod: 0), (use_distributed_rendering: 0), (use_ordered_compositing: 0)
    OpenGL Dev Render,  0.062 seconds
PropertiesPanel::Apply,  168.855 seconds
    ParaViewPipelineControllerWithRendering::UpdatePipelineBeforeDisplay,  167.877 seconds
        Execute Slice1 id: 10412,  167.855 seconds
    ParaViewPipelineControllerWithRendering::Show,  0.889 seconds
        ParaViewPipelineControllerWithRendering::Show::CreatingRepresentation,  0.856 seconds
    Still Render,  0.059 seconds
        Render (use_lod: 0), (use_distributed_rendering: 0), (use_ordered_compositing: 0)
        OpenGL Dev Render,  0.047 seconds
        OpenGL Dev Render,  0.01 seconds

Both are running locally on my workstation.

4

Hi @Yann, can you share an OpenFOAM dataset or point to a public dataset that shows this slowdown? A statefile with the property settings for the Slice filter would be helpful as well.

5

@mwestphal bugs should have been fixed. So, this is another issue. I would appreciate a dataset to replicate the behavior.

6

Hello All,
I actually ran into this same performace issue last week.
If I understand correctly the fix linked by @spyridon97 in this other thread (https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10037/diffs?commit_id=05e6ee1a0bebec86efd17312d76cbb9b740ca9fd) is for structured grids only.

I am using unstructured grids, and the performance is not great.
I found a (stupid ?) workaround: make a contour at fixed coordinates. this works way faster, but is a weird solution

7

Hi guys, thanks for your feedback.

Here is a dataset in EnSight format (the good old OpenFOAM motorbike) with a state file to get the slice.

https://www.swisstransfer.com/d/876051f2-37c8-4a02-8db8-6464d733fe44

Behavior is the same with the OpenFOAM and EnSight readers.
Considering @pcrepier’s post, could it be a general issue on unstructured grids?

8

I will take a look later today

1 Like
9

So i figured out the issue. It’s easy to fix. And it’s only related to meshes with polyhedrons (this mesh) and some other fancy cell types that were missing from a switch case.

1 Like
10

Fix is here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/11566

11

Thanks for the fix @spyridon97 !

12

Just a short remark regarding polyhedral and other fancy cell types. Modern cfd codes treat all cells as polyhedral. This is the basic cell type. Hexas and Tetras are just normal polyhedral cells. So it would be very good to develope ParaView in this direction. Unfortunately, support for polyhedra in PV is still very rudimentary.

13

I strongly disagree with your statement, making everything polyhedron is a great approach for simulation but not a viable approach for efficient, real time visualization.

14

While there are still some areas to improve, polyhedra are supported quite well in ParaView. As we work with more people in the community and identify places for improvement, support and performance will get even better.

1 Like
15

Maybe it would be worth considering converting polyhedral meshes to regular cells as a preprocessing step in ParaView? Just throwing ideas.

16

We still get this warning :frowning:

vtkPolyhedron.cxx:1800 WARN| A cell with a non-manifold triangulation has been encountered. This cell cannot be contoured.

These cells are valid within several CFD codes. So it should be also possible to use them correctly in PV.

17

There is a reason why the polys are used. One polyhedron corresponds to about 5 tetrahedrons. If we decompose a mesh beforehand, the post-processing takes significantly longer than the simulation itself and also requires more main memory. This is really not a feasible way.

18

That’s the first time i heard about this warning. Please post an issue that described the issue and provides steps to reproduce it potentially with dataset that you have (small version).

19

One polyhedron can correspond to pretty much anything 3D shaped like.

That being said, polyhedrons are very complex elements within the sci-viz domain for various reasons.

We have been trying to improve their performance lately, but we can only work on what we have funding for, or it’s contributed to VTK/ParaView.

If you wanna contribute something, feel free to do so. If you have particular needs that you would like us to resolve, please reach out to us (Kitware) to create a support contract.

Thanks a lot for your understanding.