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:
FORMAT
type: ensight gold
GEOMETRY
model: 0 1 geometry.geo
VARIABLE
scalar per element: 1 1 pressure pressure.scl
vector per element: 1 1 velocity velocity.vec
TIME
time set: 1
number of steps: 10
time values:
1.2300000E-01
2.4600001E-01
3.6900002E-01
4.9200001E-01
6.1500001E-01
7.3800004E-01
8.6100000E-01
9.8400003E-01
1.1070000E+00
1.2300000E+00
FILE
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…
-
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?
-
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.
-
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.
-
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 needs-delivery: lb_case.case(UnstructuredGridRepresentation)/GridAxes needs-delivery: lb_case.case(UnstructuredGridRepresentation)/SelectionRepresentation/Selection needs-delivery: lb_case.case(UnstructuredGridRepresentation)/SurfaceRepresentation do-delivery: lb_case.case(UnstructuredGridRepresentation)/GridAxes do-delivery: lb_case.case(UnstructuredGridRepresentation)/SelectionRepresentation/Selection do-delivery: lb_case.case(UnstructuredGridRepresentation)/SurfaceRepresentation 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.
