VTK output then read loses block id information

[GiudGiud]

VTK output then read loses block id information

[roystgnr]

Looks like we added subdomain id output back in 2013, but nobody's ever bothered to add input? The VTKIO::write-to-VTKIO::read case should be easy to fix.

I'd be paranoid that this is just one of a number of similar shortcomings, though. IIRC most of our developers have mostly used VTK as a format for visualization, not restarts.

And, while I can add the VTKIO round-trip support easily enough ... enabling Paraview conversions might be trickier. It looks like newer versions of VTK support a vtkMultiBlockDataSet, and I'm guessing that's what they use to handle block ids if anything is, but the vtkUnstructuredGrid we use doesn't seem to be related to that.

You'd think there'd still be room for subdomain identification somewhere ... but maybe that's really just a libMesh thing? Even ExodusII doesn't have subdomain info; it has "blocks" to keep hexes and the tets in separate fixed-element-type sections as a low-level data structure thing, and then we have an ugly hack where we map those to high-level-concept subdomains and just pray that users who want to put mixed element types in the same element type don't need to use Exodus.

[roystgnr]

nobody's ever bothered to add input?

Wow, I can see why. I can't find VTKIO::read() coverage anywhere in the existing libMesh tests or MOOSE tests, just a half dozen or so xmldiff'ed output tests in MOOSE tests and about as many invocations (without even diff testing) in libMesh examples. Someone did add a bit of read() support at one time, but the most recently I can see it getting real attention in the git logs was 2016.

Trying to write new tests, I can't even figure out what you must be doing, since our support for VTK reads is so bad. Trying to write .vtu currently complains and dies (because we just make everyone use .pvtu now), but trying to do a name-based read of .pvtu fails (because we never added it alongside .vtu to the list of suffixes to check), and if I fix that then doing any read of .pvtu fails (because we use vtkXMLPUnstructuredGridWriter but we only use vtkXMLUnstructuredGridReader without the P).

Any way, I've got like 5 fixes coming down the pipe in libMesh, so whatever you're doing, is there any way we can get a quick regression test (for the non-broken aspects of it) into MOOSE? It's scary to edit code with zero test coverage...

[GiudGiud]

I was just trying to read a mesh file that I only had in this vtu format. And I had output it in that format to provide it to someone for them to use in StarCCM.
But then they started using MOOSE and were struggling to read it.

[GiudGiud]

But yeah I did not end up reading in the .vtu. I converted it to exodus using Paraview then grabbed the EEIDs like this:

[Mesh]
    [fmg]
        type = FileMeshGenerator
        file = 'mesh.e'
        exodus_extra_element_integers = 'subdomain_id processor_id'
    []
    [convert_eeid_to_blocks_0]
        type = ParsedSubdomainMeshGenerator
        input = fmg
        block_id = 9
        combinatorial_geometry = 'subdomain_id<2'
        extra_element_id_names = 'subdomain_id'
        show_info = true
    []
    [convert_eeid_to_blocks_1]
        type = ParsedSubdomainMeshGenerator
        input = convert_eeid_to_blocks_0
        block_id = 20
        combinatorial_geometry = 'subdomain_id>10'
        extra_element_id_names = 'subdomain_id'
        show_info = true
    []
[]

[roystgnr]

.pvtu reads are actually quite horrifying to try to fix.

How is any software supposed to piece together connectivity here? Points on multiple processors get written out on each, with no ids, nothing to say whether they're ghosting/sharing other processors' points or whether they're independent ... and it doesn't look like this is our fault; I can't find anything along those lines in https://vtk.org/wp-content/uploads/2015/04/file-formats.pdf either.

Looking at the Information tab in a .pvtu loaded in Paraview, it doesn't even bother trying to connect up the individual pieces, it just happily reports that a 16-node mesh has 21 nodes because it saw 5 duplicates.

I'm thinking of adding a "libmesh_node_id" array to go along with "libmesh_elem_id", and then just refusing to load any file split across more than one processor unless it has node ids. We could try stitching by node location, but that's not the sort of thing to do automatically unless we want one-in-a-billion failures on problems with moving meshes and one-in-one failures on problems with slit meshes.