Support writing of hex elements to VTKHDF format.

[pshriwise]

Description

This includes updates to the VTKHDF writer method so that its capabilities match those of the other VTK formats (.vtk/.vtu) supported by UnstructuredMesh.write_data_to_vtk).

Partially addresses #3620

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 15) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[pshriwise]

@jon-proximafusion I meant to mention to you a change in design from creating a dataset and appending to creation of the dataset with the data directly. Because we're working with statically sized datasets here (once we've determined the connectivity), creating them with the necessary size from the onset seemed to make the most sense to me.

Of course do let me know if that's not considered best practice for these files as the format is quite new to me.

[shimwell]

The code looks good to me @pshriwise
I think your redesign to creating arrays with the necessary size from the onset is a good one.
I've not been able to run this locally (I will need to install libmesh for that) so I was very happy to see you have extended the tests as well.
Tagging @mwestphal to show that we are continuing the hdfvtk which I think he will be happy with seeing the impact of his work.

[shimwell]

@aprilnovak wondering if this PR is of use to you workflow that involves different mesh element types to tets. If you are using libmesh with mixed element types then this PR might be of interest.

[aprilnovak]

Right now we write tallies via MOOSE's output files since we do the coupling in-memory (as opposed to via files), but it's nice to see this feature supported!

[shimwell]

I don't think this is a blocking issue but wanted to mention it in case it comes up in the future.

CellData array size when unsupported elements are skipped

I think there may be a subtle issue when n_skipped > 0. The VTKHDF file gets NumberOfCells = n_cells (excluding skipped elements), but the CellData arrays are still written with self.n_elements entries since the dataset validation at line 3149 checks against self.dimension. I think the VTKHDF spec expects CellData arrays to match NumberOfCells exactly, so a VTK reader might reject or misinterpret the file in that case.

Looking at the C++ side (src/mesh.cpp:988-991), UNSUPPORTED elements can occur for any element with connectivity size != 4 and != 8, so I think this is a scenario that could realistically come up for wedges/pyramids.

The ASCII writer has a similar pre-existing pattern, but I think VTK's Python API is more forgiving about array length mismatches than the strict HDF5 format.

[shimwell]

LGTM after waiting 2 days for any other comments

[paulromano]

This file is missing in the PR. When I run locally, it fails. Not sure why it was passing on CI?

[shimwell]

oh there is a skip on the tests that might explain this