Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect VTK configuration flag suggested by configure #3734

Open
jvwilliams23 opened this issue Dec 1, 2023 · 9 comments
Open

Incorrect VTK configuration flag suggested by configure #3734

jvwilliams23 opened this issue Dec 1, 2023 · 9 comments

Comments

@jvwilliams23
Copy link

Hi,

This is related to #3665 (fixed by @roystgnr).

I was compiling libMesh with VTK (tried 9.3.0 and 9.0.3), but when I managed to get configure to find the headers, it could not compile the test program. I got the following output with VTK-9.0.3:

checking for vtkConfigure.h... yes
checking for vtkVersionMacros.h... yes
<<< Linking a test program against the VTK libraries failed >>>
<<< libMesh requires VTK to be configured with -DVTK_Group_MPI:BOOL=ON >>>

I then recompiled VTK with VTK_Group_MPI, but it said this was an unused variable. The suggested flag should be -DVTK_USE_MPI:BOOL=ON.

Should just require changing configure.

Best,
Josh

@roystgnr
Copy link
Member

roystgnr commented Dec 3, 2023

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
Copy link
Author

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

@CBqk3762
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link

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

@roystgnr
Copy link
Member

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
Copy link

CBqk3762 commented Jun 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants