I just published the first release of the fVTKHDF library, which provides a high-level, objected-oriented Fortran interface for writing VTKHDF files. This is a relatively new HDF5-based VTK file format used by ParaView. The library is designed for MPI-parallel high-performance computing applications. It uses parallel HDF5 (via MPI-IO) to enable all MPI ranks to collectively write to a single shared file. By utilizing HDF5 as the underlying storage mechanism, the VTKHDF format is a more scalable alternative to older VTK ASCII or XML formats.
More info and a Reference Manual are available at the project’s github website.
This looks very interesting. Coming from a CFD background, I can see me using this instead of something like CGNS. However, I would like to see some support for structured or semi-structured grids (think overset or chimera grids). The path of least resistance would be a utility that can convert the structured mesh (hex or quads) into an unstructured one. Making a quick and very uneducated guess, this could just be a matter of indexing. Can your code already do something like this.
No, it’s designed for a close 1-1 correspondence between the interface data and the structure of the VTK dataset (e.g. UnstructuredGrid). Other than a translation from 1-based indexing to 0-based indexing, it doesn’t try to translate from one mesh structure to another.
Looking at the VTKHDF implementation status it looks like there are VTK dataset types that might fit with your interests (vtkRectilinearGrid, vtkStructuredGrid, vtkHyperTreeGrid(?)). But except for the last one, these (seemingly the easiest) haven’t had their VTKHDF format specified yet (and no reader obviously). I don’t know what the last one is.
I am unlikely to implement any of the other VTKHDF format types (AMR, Image, Poly, …) in fVTKHDF myself. If someone was a user of one of these formats and very familiar with it, I’d welcome code contributions.
Thanks. While most of the world has gone unstructured, there are still widely used codes out there that use structured grids (both body-fitted and cartesian). Two examples are the Sandia CTH hydrocode which I have a lot of experience with and NASAs CART3D CFD code. I’ve written my own code to generate VTK classic format files to support CFD and Structural Dynamics but your code looks to be a major improvement.
Edit: As I stated above I only support the original ASCII file format (both formatted and binary). I was working on implementing XML (even had my own BASE64 encoding software implemented) but decided it wasn’t worth the extra effort. Also, I found out after I had my original software implemented, that a better package than mine already existed see.
the parallel file formats, where the mesh is divided into pieces
the .pvd format, essentially a header which allows grouping an entire time-series
But I agree the need for base64 encoding is cumbersome. It has been discussed a couple times on FD already.
In the last couple of years Kitware also added new cell types, for instance arbitrary order Lagrange elements (see Modeling Arbitrary-order Lagrange Finite Elements in the Visualization Toolkit). I’ve always wondered if these would work also with the legacy VTK format. In theory it’s just picking the right integer for the CELL_TYPES field and making sure the DoFs are sorted in the right way (). The enumerators can be found in the vtkCellType.h header.
There were a couple of blog posts about the new VTK HDF format and a couple of related features:
My last iteration of my VTK code was to add support for a couple of HO Finite Elements. The element types were already supported in VTK but the nodal order was different than the application I was extracting data from used, While having the ability to do arbitrary order elements is nice, A couple people I know who have a lot more experience with FEM than I do have argued that going past quadratic and in some cases cubic elements doesn’t really buy you much for most real world applications. However I do know some application areas (turbulence modeling and aeroacoustics ) were you can gain a lot if you use high-order methods for both the temporal and spatial discretizations.
). The enumerators can be found in the