vtkHyperTreeGrid reader support

[alhom]

HyperTreeGrid writer support has been implemented:
#18686

It could be useful to expand support to allow for reading HTG data structures as well! I do not know, however, how well HTGs are supported in VisIt otherwise.

Is your feature request specific to a data set?

I believe there are ok toy models that can be derived from these:
https://www.kitware.com/hypertreegrid-in-vtk-data-construction/

Describe the solution you'd like.

A reader for vtkHyperTreeGrid data.

Additional context

We work on tree-based adaptive Cartesian meshes, for which HTG support would be rather nice.

Describe alternatives you've considered.

We have our own file format, and a VisIt plugin for it; more useful for us might be to rework out plugin to form and expose a HTG - if the HTGs work on VisIt, that is. Rounding out the existing writer with a reader might still be a nice thing to do :).

[markcmiller86]

@alhom...in your submission you explain that an HTG reader "could be useful" or "would be rather nice". You go on to explain that "we have our own file format, and a VisIt plugin for it".

So, I guess I am confused. Can you please explain what problem(s) you are facing that expending resources to develop an HTG reader will address?

Maybe the plugin you have is sufficient? If so, maybe you would like to submit a PR here to add your plugin? That would be neat.

If you are planning on that, please be aware that we will also need test data, tests and documentation to accompany it along with a modest committment from you to help us keep it up to date as VTK changes.

[alhom]

Hi!

Yes, I did went off on a tangent more suited to the discussions, there! On one hand, I'm not sure how/if HTG meshes are supported in VisIt. On the other hand, I probably should open a discussion for our plugin, since it does have plenty of room for optimization and fixes for mesh stitching - but that should be another matter.

As for the HTG reader, I believe it would be useful for us as mostly a reference implementation. For now, I'm testing the HTG description for our data on ParaView, which does seem to work decently (after a conversion to .htg). I think feature parity and symmetric implementation of writing and reading formats would be rather desirable in general, but there is no pressing need on our end.