Transient ensight gold case file for ParaView - performance

I am having second thoughts on my current implementation of ensight gold result files.
The constraints are rather simple: I have a single geometry which does not change over time, i.e. the geometry.geo file only contains one entry, encased by “BEGIN TIME STEP” and “END TIME STEP” as is necessary according to the ensight manual. And I have several data files (only two in this example) with values that do change over time, i.e. one entry for each time step.
This is what my case file looks like:

type: ensight gold

model: 0 1 geometry.geo

scalar per element: 1 1 pressure pressure.scl
vector per element: 1 1 velocity velocity.vec

time set: 1
number of steps:           10
time values:

file set: 1
number of steps:           10

First things first: it works. I can also run Paraview in MPI mode and switch around between time steps.
What I am not sure about: is this the “right” way to do it with my constraints? (static geometry with time-dependent values)
Particularly with respect to performance. Switching between time steps takes quite some time. Some of it is surely taken up by reading the new result values. But I am not 100% sure if PV assumes that the geometry also changes over time, and reconstructs it for every new time step. Which would be unnecessary in my case. The progress bar for “GeometryRepresentationWithFaces” takes longest when switching between time steps.
Could anyone share some insight into this? The ensight manual is not particularly helpful here, at least not for me.

I just tried some things…

  1. Writing one geometry representation per time step to the geo file, and changing the case file accordingly. Switching between time steps takes just as long as it did with a single geometry representation. So I guess PV rebuilds the geometry every time step, even with a constant geometry?

  2. Instead of showing the whole model with a surface representation, just show a slice through the geometry. Switching between time steps is much faster now.

  3. Enabling geometry buffer in PV with a large enough buffer size to fit everything. After switching through all time steps once, the second time cycling through them is sped up immensely.

  4. Enabling timer log. For switching between two time steps (again, only one time step present for the geometry, having the full model visible as “Surface”, and no cached geometry), this is the result:

     RenderView::Update,  1.46903 seconds
     vtkPVView::Update,  1.46821 seconds
         Execute vtkPGenericEnSightReader id: 8388,  0.27751 seconds
         Execute vtkGeometryRepresentationWithFaces id: 8758,  1.16194 seconds
             vtkPVGeometryFilter::RequestData,  1.15596 seconds
                 vtkPVGeometryFilter::RequestCompositeData,  1.15593 seconds
                     vtkPVGeometryFilter::ExecuteCompositeDataSet,  1.15585 seconds
     ensight::GatherInformation,  0.033425 seconds
     Still Render,  0.09119 seconds
     Render (use_lod: 0), (use_distributed_rendering: 0), (use_ordered_compositing: 0)
     OpenGL Dev Render,  0.087481 seconds

I know, times look rather short here. But it’s a small example with ~4 million cells, my usual models are much larger in the range of 50-200 million cells.
So is this a Paraview thing? Rebuilding the entire geometry representation for every time step, even though the geometry does not change.
Is there something I can change in PVs settings, or in my ensight gold case file, in order to speed things up? Geometry caching is obviously not a solution, as that only helps the second time a time step is loaded, and I am only cycling though each of them once. And with really large models and more time steps, I would run out of memory anyway.

You are in luck : :slight_smile:


Damn, seems like I asked at exactly the right time.
While I probably can’t use the current state of this plugin for everything I do, It sure will come in handy sometimes. And I know that I was not doing it completely wrong all those years.

I had mostly given up on this on. Nice to see it’s now there!

1 Like

Follow-up question: in the “limitations” section, the article states: The vtkStaticcPlaneCutter and vtkForceStaticMesh applied on a multiblock dataset only process the first block.

My geometry in ensight gold terminology always consists of a single part, made up of hexa8 elements. Loading it into ParaView, it is interpreted as a multiblock dataset. Do I still only have a single single block in ParaView terminology? I.e. will this plugin be useful for me?

If I understand well, this plugin in its current form will not be as usefull as it could be.
However, by using ForceStaticMesh filter, you can still use it.