Query regarding reading comments inserted into .VTU files

Hi, I’m working with xml .VTU files and I’d like to add a comment in the top line xml header that para-view won’t interpret or throw an error with and I’m unsure what specific text is safe here.

Something along the lines of:

<VTKFile type="UnstructuredGrid" version="1.0" comment="comment text" byte_order="LittleEndian" header_type="UInt32">

Where comment is arbitrary data that para-view doesn’t care about.

I know I can add extra data further down the file itself however this is for a CFD research flow solver and it works out easier to maintain my codebase keeping stuff on the first line of the file if I can.

For completeness of the question my exact file structure is as follows:

<VTKFile type="UnstructuredGrid" version="1.0" byte_order="LittleEndian" header_type="UInt32">
  <UnstructuredGrid>
    <Piece NumberOfPoints="" NumberOfCells="">
      <Points>
        <DataArray> [Coordinates] </DataArray>
      </Points>
      <Cells>
        <DataArray> [MESHDATA] </DataArray>
      </Cells>
      <PointData>
        <DataArray> [POINTDATA] </DataArray>
      </PointData>
    </Piece>
  </UnstructuredGrid>

  <AppendedData encoding="raw">_
    [appended raw binary data] 
  </AppendedData>
</VTKFile>

(Yes I know raw binary is technically a violation of xml format but I’ve never worked with xmls prior to this project so the xml police can fight me for it.)

Id expect that to work out of the box tbh, does it ?

Please consider using VTKHDF instead by the way, the spec does specify how to add you own data that will be ignored: VTKHDF format specification - VTK documentation

1 Like

Hi, yeah I tried before making the post however paraview threw up an error interpreting it, though in retrospect its possible the editor I was using broke the appended data. I’m being pretty hasty atm throwing stuff together because I’m on a bit of a tight turnaround so I was a bit sloppy. Once I find the time I’ll double check for the sake of due diligence.

Irregardless I realised that there is an xml standard for comments in:

<!-- [COMMENT] -->

which works well enough for my purposes.

Regarding HDF, I did consider using them for this project however I think with the way I’m exporting my results they would impact the performance of my work. This is for an unsteady CFD code for problems around Mach 7 so I believe the cost of writing the partition data (ghost points) in HDF may be significant as compared to my current method that writes result data from different partitions by redefining the partition view of the results file from a global reference frame to a local one and then treating it as a contiguous write.

It’s possible I overlooked something when reading the HDF standard w.r.t. performance but this is just the cost of learning what’s worth doing and what isn’t, I would not be surprised if I live to regret the xml writer.

1 Like

What you do with XML format, you can do with vtkhdf as well :slight_smile:

1 Like

Yes of course it can, sorry. Had a momentary blank.
If I ever get round to it I’ll implement hdf and properly benchmark the write performance.

Am I correct in the belief the hdf reader Paraview uses is likely faster than the xml format reader because of a better parallel implementation?

It is definitely better when reading the same data mutliples times in a temporal context, other than that, we are working on a benchmark to provide actual numbers.

With HDF can you have one file that contains multiple sets of temporal data on multiple meshes for things like runtime mesh refinement codes? And will paraview’s filters generally support this?

ie, starting with mesh A, refined to B, refined to C:

---------------------------------------------------------------------------
time |    1    2    3    4    5    6    7    8    9    
mesh |    A    A    A    B    B    C    C    C    C

I remember struggling to fully wrap my head around the hdf format in specifics when I looked last and concluded I couldn’t but I expect I just misunderstood it.

Yes, thats exactly what you can do. And yes, filters supports that, some filters even optimize for such usecase and avoid recompuation in that case. It is called static mesh.

You can find more info here: https://www.kitware.com/vtkhdf-file-format-2025-status-update/

Look at this tutorial specifically: https://gitlab.kitware.com/keu-public/vtkhdf/vtkhdf-scripts/-/tree/main/tutorial?ref_type=heads#time-steps

1 Like

Champion, thanks

1 Like