The .pvtu extension should be used when writing VTK files in libMesh

[rcontinuum]

Hello,
I just want to share the following observation:

If I set in [Outputs] vtk = true [] and execute an input file in serial mode I get a group of vtk and vtu files like

test_out_000.vtk
test_out_001.vtk
test_out_000_0.vtu
test_out_001_0.vtu

Now, if I open the groups of vtk-files in paraview then I get a paraview error "A reader for ".../test_out_000.vtk" could not be found".
I tried paraview versions 5.9.1 and 5.5.2 (from the paraview download page).
If I rename the *.vtk-files to *.pvtu-files then paraview loads the renamed files with no error.
In the case I run a moose app in parallel *.pvtu-files are written and the problem does not occur.

The moose app gives in serial mode a hint "The .pvtu extension should be used when writing VTK files in libMesh."
In https://mooseframework.inl.gov/docs/doxygen/libmesh/vtk__io_8C_source.html around line 256
one finds a comment that vtk-files would work too, but maybe that is not correct anymore.

Edit: typo

[GiudGiud]

Hello

I just tried on a sample input file with paraview 5.9.1 on mac and was able to open the .vtu file generated by MOOSE.
I think you need to open the .vtu file with paraview, not the .vtk file.

Guillaume

[rcontinuum]

Thank you for looking into this.
Yes, I can open the vtu-files too. But only single ones, i.e. one at a time. paraview (on linux) does not identify the vtu-files as a group.
See my screenshot

It could be due to the numbering of the vtu-files. Both end with _0, which may mean "Piece" number 0? Whereas the generated vtk-files have consecutive numbers at the end, _000.vtk and _001.vtk. The vtk-files are just files which basically "point" to the corresponding vtu-file (which contain the "real" simulation data).
Like in test_out_000.vtk

...
<Piece Source="test_out_000_0.vtu"/>
...

If I do in a bash terminal: mmv "*.vtk" "#1.pvtu" (rename all *.vtk to *.pvtu; multiple move) then these renamed files get identified as a pvtu-group too and can be opened as a group of files with no error message. And I can play the fields as a "movie/animation". Basically I assume, paraview "runs" through the group of pvtu-files and loads the corresponding "real" simulation data from the corresponding vtu-files.

Do you see the same behavior on Mac?

I mean, if yes it should be a simple modification in the source code. Basically, always write files with pvtu-ending (in serial and parallel) "pointing" to the vtu-files which contains the "real" data. Just use always the ending .pvtu instead of .vtk (in searial mode).

Ralf
PS: Sure, I can always perform a mmv "*.vtk" "#1.pvtu"after the run. So, it's nothing essential.

[GiudGiud]

Paraview will let you load more files from the GUI I think.

I dont know why we have the _0, suffix on the .vtu. I think it makes sense for the .pvtu.
@roystgnr any ideas on this?

[roystgnr]

Looks like we're writing out pvtu format even in serial right now (or at least we're handing an MPI communicator to VTK and that's what it's deciding to do in that case), with a comment in the libMesh source saying this is fine since Paraview understands that special case. So you ask VTKIO to write "foo.pvtu", and it writes the header data to that, and then it writes a "foo_#.vtu" file for each processor rank #. The catch is that, if you ask for an extension other than pvtu, we yell at you but then we do as you say, and Paraview etc. don't understand that. So unless we want to add special-case code to an already undermaintained code path, the fix might be to just have Moose VTKOutput.C always ask for a .pvtu extension?

But I must still not be understanding this, because: how is this a problem cropping up now? The patch enabling parallel writes and warning about non-pvtu extensions went into libMesh nearly 9 years ago, and it looks like John was editing the Moose output to match years later than that.

[GiudGiud]

people were probably loading up the vtu instead of the vtk file.
So sounds like we just need to write pvtu instead of vtk to be good here

[rcontinuum]

Background: I was playing around with vtk = true and thought the MOOSE VTK-output files are not fully behaving like I would expect in serial mode. But in parallel mode it behave like I expected (from a user point of view using paraview). I (intent to) use vtk-files for development/debugging, typically meshes with one or a few elements, as they are in ASCII. And an exodus-file needs ncdump to make them readable for a human.
I just wanted to report my observation. I mean, it's no a big deal for me, I can always rename with mmv.

the fix might be to just have Moose VTKOutput.C always ask for a .pvtu extension?

That was at least my first thought and even if I'm not familiar with your code I thought that should by like modifying "one" line of code (which is a "dangerous" assumption from my side). I don't know the precise VTK definition of "parallel" files, but in principle they should work for "n=1", i.e. serial, too.

how is this a problem cropping up now?

I started with looking into MOOSE recently, so I cannot tell you.
Maybe paraview (or VTK-lib) a few years ago was not that "picky" concerning *.vtk and *.pvtu extensions and their content. But this is a speculation from my side.

[rcontinuum]

Shall I open an issue on this topic?

[GiudGiud]

Sure but its a libmesh issue i think

[GiudGiud]

Please make sure to document the workaround there btw

[roystgnr]

It's a Moose issue, and at least in theory it was noted in #19581 and fixed by #19582 last week. Looks like Github doesn't automatically generate backlinks to referenced discussions the way it does to issues and PRs? That's annoying. Sorry, I'd have mentioned it here manually if I'd known that was necessary.

[rcontinuum]

Thank you for fixing this so fast!

[rcontinuum]

Sorry, I'd have mentioned it here manually if I'd known that was necessary.

Well, at least now I see in the right most column of this page after scrolling up "Events".