libmesh
libmesh copied to clipboard
Failed to Build DTK Solution Transfer Example
When using make check
to build and run the examples, the DTK solution transfer example fails. A series of errors related to the main.c
file for that problem occur:
...undefined reference to 'libMesh::DTKSolutionTransfer::DTKSolutionTransfer(libMesh::Parallel::Communicator const&)'
...undefined reference to 'libMesh::DTKSolutionTransfer:transfer(libMesh::Variable const&, libMesh::Variable const&)'
...undefined reference to 'libMesh::DTKSolutionTransfer::~DTKSolutionTransfer()'
These errors then cause example-opt
to fail to build.
I configure libmesh with the following options:
--enable-trilinos
--enable-mpi
--with-trilinos={Path to Trilinos install}
--with-dtk={Path to DTK install}
--with-methods=opt
--prefix={Path to libMesh target installation}
Based on the configure summary, the specified options are all enabled and nothing is missing. If I leave Trilinos and DTK disabled, then make check
runs without any problems. I'm using libMesh v1.0.0 and DTK v2.0 with the libMesh adapters enabled.
For setting up libMesh and DTK, I installed libMesh and then installed DTK with the libMesh adapters enabled. Once DTK was installed, I then reinstalled libMesh with DTK and Trilinos enabled. I'm not 100% clear on how the two codes interact, so I might have something out of order here. My end goal is something very close to the solution transfer example from libMesh, so any help getting that example working would be appreciated.
Could you double-check your libmesh_config.h and make sure LIBMESH_TRILINOS_HAVE_DTK is defined?
Although honestly I don't see how this exact error could happen. If that macro wasn't defined it should have commented out the headers, not just the source, and then you'd have gotten a compiler rather than a linker error. dtk_solution_transfer.C is still in libmesh_SOURCES, so we can't be forgetting to compile it entirely. (although to be sure, would you check and make sure the corresponding object file did get generated for you?)
After that I'm not sure what to check. Run "nm" on the object file and on the shared library to make sure that destructor got built?
libmesh_config.h
has the following:
/* Flag indicating whether the library shall be compiled to use the DataTransferKit */ #ifndef LIBMESH_TRILINOS_HAVE_DTK #define LIBMESH_TRILINOS_HAVE_DTK 1 #endif
There is an object file in the ...libmesh/build/examples/solution_transfer/solution_transfer_ex1
folder. Running nm
on example_opt-main.o
generates an output. Which shared library should I be checking?
Try running (with c++filt installed)
nm src/solution_transfer/.libs/libmesh_opt_la-dtk_solution_transfer.o | c++filt | grep '~' | grep -v std
and see if it shows the ~DTKSolutionTransfer destructor?
If that works try
nm .libs/libmesh_devel.so | c++filt | grep '~D'
(both from the top of your build directory)
The first command worked, but the the second one didn't find anything. So that means I'm missing that library then?
Oh, I'm an idiot, sorry. Try
nm .libs/libmesh_opt.so | c++filt | grep '~D'
I noticed you were building in opt mode but then I just picked out a devel mode filename at random.
By "worked" I take it that the DTKSolutionTransfer destructor really is there?
Ok, now I get an output for both commands. In both cases, I get 3 instances of
T libMesh::DTKSolutionTransfer::~DTKSolutionTransfer()
. So it looks like the destructor is there
Since I can find the destructor, do you have any other suggestions for what I should check or what might be missing? I've tried reinstalling both libMesh and DTK and I still get the same errors.
My only other idea is that my installation procedure is causing an issue. I've been doing:
- Install libMesh without DTK or Trilinos enabled
- Install Trilinos with DTK (libMesh adapters are enabled)
- Reinstall libMesh with DTK and Trilinos enabled
It seems strange to me installing libMesh twice, but it's the only way I can think of to provide the required files for each program's adapters. Unless I only actually need the DTK adapters (from libMesh) to make this work
... that could definitely be causing the issue. You've got Trilinos linking against one libmesh_opt.so, you're building a different libmesh_opt.so, and if the two are getting linked together then who knows what's going on, but "linker is looking in the wrong library" is definitely a prime suspect.
I'm afraid I'm not familiar enough with DTK to tell you what the right way to do this is, though.
I reinstalled DTK without the libMesh adapters and then installed libMesh with the DTK adapters. Now all of the libMesh examples (including the DTK solution transfer) build and run. The way I installed everything was what caused my issues.
Even though the libMesh self-checks say the DTK example works, the plotted results look questionable. Of course this might be related to the DTK installation and not libMesh at all. It looks like a solution is transferred between the meshes, but not the original one.
Do you know if there are reference solutions for the libMesh examples anywhere? I found this page, but am more interested in plots of the meshes. My mesh information is the same as what's listed there though.
I reinstalled DTK without the libMesh adapters and then installed libMesh with the DTK adapters. Now all of the libMesh examples (including the DTK solution transfer) build and run. The way I installed everything was what caused my issues.
Even though the libMesh self-checks say the DTK example works, the plotted results look questionable. Of course this might be related to the DTK installation and not libMesh at all. It looks like a solution is transferred between the meshes, but not the original one.
Do you know if there are reference solutions for the libMesh examples anywhere? I found this page, but am more interested in plots of the meshes. My mesh information is the same as what's listed there though.
I met the same problem.