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 !