Incorrect VTK configuration flag suggested by configure

[jvwilliams23]

Incorrect VTK configuration flag suggested by configure

[roystgnr]

VTK_Group_MPI should be the suggested flag with older versions of VTK. I guess at this point in a configuration we have the vtk header, so we might detect version from that and try to map to configure flag ... but if that's a moving target, do you think it would be reasonable to just suggest "requires VTK to be configured with MPI support"?

[jvwilliams23]

Yeah I think that would be reasonable. I have rarely seen a package give an exact compilation flag for a dependency.

[CBqk3762]

I am having problems that I think this may be related to this, I am trying to have MOOSE read in a .vtu mesh which I was under the impression should be possible due to its' use of libmesh. But I get an error around libmesh failing to read the mesh:

*** ERROR ***
Cannot read VTK file: /home/cbyers/projects/moose-chimera/water_boatman/run/breeder_unit/in/breeder_unit.vtu
You must have VTK installed and correctly configured to read VTK meshes.
Stack frames: 18
0: libMesh::print_trace(std::ostream&)
1: libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*, std::ostream&)
2: libMesh::VTKIO::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
3: libMesh::NameBasedIO::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
4: libMesh::UnstructuredMesh::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void*, bool, bool)
5: FileMesh::buildMesh()
6: MooseMesh::init()
7: SetupMeshAction::act()
8: Action::timedAct()
9: ActionWarehouse::executeActionsWithAction(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
10: ActionWarehouse::executeAllActions()
11: MooseApp::runInputFile()
12: MooseApp::run()
13: ../../water_boatman-opt(+0xdcb3) [0x55789ab98cb3]
14: main
15: /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7f241804624a]
16: __libc_start_main
17: ../../water_boatman-opt(+0xdfe1) [0x55789ab98fe1]
[0] ../src/mesh/vtk_io.C, line 761, compiled May 23 2024 at 10:55:35


Stack frames: 9
0: libMesh::print_trace(std::ostream&)
1: moose::internal::mooseErrorRaw(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
2: void mooseError<char const*>(char const*&&)
3: /home/cbyers/projects/moose/framework/libmoose-opt.so.0(+0xe1507c) [0x7f242181507c]
4: ../../water_boatman-opt(+0xdcb3) [0x55789ab98cb3]
5: main
6: /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7f241804624a]
7: __libc_start_main
8: ../../water_boatman-opt(+0xdfe1) [0x55789ab98fe1]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------

I have tried installing VTK manually and then running the MOOSE script that reconfigures and installs libmesh with flags in accordance with MOOSE's instructions https://mooseframework.inl.gov/help/faq/faq_build_libmesh-vtk.html , so the paths to VTK's lib and include are given explicitly.
The only warning I get while this runs is in regards to the position of libtool, but it simply gets reinstalled so I don't see that being the problem.
This didn't change the error I get. I made sure to recompile my moose app too after running this, which should ensure any links are passed on. I am able to run problems that don't involve reading in a vtu mesh.

I have also tried recreating the vtu file (from an exodus file created in cubit, using meshio for the conversion), all of this appears fine. And VTK itself is able to read my vtu file also.

Apologies if I've missed something obvious and this is actually an issue with MOOSE.

[jvwilliams23]

HI @CBqk3762
An easy check to first see if VTK is installed correctly would be to try run a MOOSE example with the vtk = true in [Outputs]. Could you let me know if that works?

[CBqk3762]

Hi @jvwilliams23
Thanks for getting back to me so quickly!
It seems like the issue might be in MOOSE, I just get a warning here, but it seems more like my configuration is wrong for libmesh rather than it not being found?

*** Warning ***
/home/cbyers/projects/moose/examples/ex03_coupling/ex03.i:72.1:
The following warning occurred in the Action 'Outputs' of type CommonOutputAction.

VTK output requested but not enabled through libMesh

[jvwilliams23]

Yes seems your libmesh is not picking up VTK. I had that problem before a while ago, and just ended up moving on (I do need to go back and do it at some point though). Maybe worth trying a clean MOOSE/libmesh installation, instead of rebuilding an existing one.

[CBqk3762]

Okay, I will give it a go, thanks for your help!

[roystgnr]

Apologies if I've missed something obvious and this is actually an issue with MOOSE.

"You must have VTK installed and correctly configured to read VTK meshes." is a libMesh message; if you see that then your libMesh build didn't manage to detect a usable VTK, and there's nothing MOOSE can do at that point. We generally don't give more than a warning at libMesh configure time when that detection failure happens, though, since the rest of libMesh is still usable without VTK. We do have a --enable-vtk-required option for users who demand VTK, but it looks like the MOOSE scripts don't turn that on (reasonably, since most of MOOSE is also usable without VTK, and since compatibility changes between versions have made it a hassle for some users in the past).

You might be able to search through the libMesh config.log to see whether it's failing to find VTK headers or failing to build against the library or failing to find MPI support or what.

[CBqk3762]

I believe I've found the source of the problem, when VTK moved to 9.1 vtkConfigure.h was split across multiple other headers and deprecated https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/release/9.1.md#filters-2 , libmesh can't find it (or vtkVersionMacros.h, but one at a time!) so fails.

I am personally using a much older version of VTK (8.2.0) for now as I am working to a deadline, after that I could work on a patch if there isn't the bandwidth. I guess it just needs to be changed to check for the headers then if it doesn't find them check for some of the functions moved from those original headers in the other headers (hopefully that sentence makes sense!) before returning an error.