Longstanding changes to OpenFOAM infrastructure for improving the handling of VTK output and paraview interfaces.
Follows up on work started with 1612 (the vtk output formatters). At that stage, we had introduced foam-vtk-cells in the attempt to consolidate vtkTopo (from foamToVTK), some bits and pieces from a foamToVTU utility and of course the paraview reader module. Each of these did something somewhat similar: namely convert OpenFOAM volume meshes into VTK formats, plus some additional management of polyhedral decomposition (since VTK still isn't the best with these). However, each of the applications have very slightly different requirements on the output format (legacy vs xml etc). Reducing the memory overhead and improving the overall performance of the paraview reader module was an additional driving factor. The latter becoming quite important if we wish to target a catalyst interface.
The key points of the updated infrastructure:
- dimensioning analysis for OpenFOAM -> VTK conversion now stored and encapsulated as foamVtuSizing.
- copying of OpenFOAM mesh types to VTK types is now done as a service method (algorithm) from foamVtuSizing, with storage being administer elsewhere outside of the class. This lets us target various combinations of output format (legacy, xml, vtk-internal) and storage primitives (int32, int64) and storage types (OpenFOAM List, std::vector, VTK storage classes) without code duplication. This lets us leverage the OpenFOAM infrastructure when populating the VTK classes and handle the different API sizings (eg, OpenFOAM label vs VTK vtkIdType) and the different mesh layouts with the minimal level of overhead.
- Revamped paraview reader module to cache the VTK grid and only shallow copy it when changing time-steps (when the OpenFOAM mesh itself doesn't change). The storage change also makes it easier to understand what the reader module is actually doing.
- Extended the formatting support for legacy and also xml formats.
- Now possible to emit VTU, VTP files from foamToVTK. This makes for easier loading of results and with xml formats we can start grouping multiblock files etc in the future.
- propagated the newer formatting options to reduce overall code clutter in most places where vtk output was being generated. This will still need more attention, but is largely complete.