We’ve been using the .pvd file format for storing results (and ParaView for visualization/analysis) from our Coreform Flex isogeometric analysis solver for a few years and have some features requested by our customers that have us wondering whether a different format would be better suited for our needs.
Writing to the PVD format appears to create a bunch of files (per process, per timestep):
my_results.pvdmy_results_ts000001.pvtumy_results_ts000001_0.vtu- …
my_results_ts000001_{n-1}.vtu
my_results_ts000002.pvtumy_results_ts000002_0.vtu- …
my_results_ts000002_{n-1}.vtu
Often leading to (tens of) thousands of files. Furthermore, it’s unclear to us whether we can assign metadata to define subsets, such as sets used for boundary conditions, or sets defining part instances to support toggling visibility / inclusion in pipeline objects - so today we write each set / part instance to its own top-level PVD file (bolt_1.pvd, bolt_2.pvd, … bolt_100.pvd, gasket_1.pvd, …, load_surface.pvd, x_symmetry.pvd, …) each with its own “file-explosion” underneath it.
Our customers would prefer a single output file (e.g., Abaqus .odb, ANSYS .rst) or at least a format that could be combined into a single file if per-process writing is more efficient in a one-partial-file-per-process manner (e.g., Exodus → epu my_results.128.001 --auto → my_results.e). We’d also like to still be able to define cells using cell-types like Bezier Hexahedron etc.
More or less, we’re interested in the same breadth of functionality / ease-of-use available to Exodus files in ParaView (Exodus isn’t compatible with our solver technology), and we’re wondering if XDMF (or some other format) would be more suited to our needs than PVD.
