libmesh icon indicating copy to clipboard operation
libmesh copied to clipboard

Failed to Build DTK Solution Transfer Example

Open PeterK26 opened this issue 5 years ago • 12 comments

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.

PeterK26 avatar May 13 '19 19:05 PeterK26

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?

roystgnr avatar May 13 '19 19:05 roystgnr

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?

PeterK26 avatar May 13 '19 20:05 PeterK26

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'

roystgnr avatar May 13 '19 22:05 roystgnr

(both from the top of your build directory)

roystgnr avatar May 13 '19 22:05 roystgnr

The first command worked, but the the second one didn't find anything. So that means I'm missing that library then?

PeterK26 avatar May 13 '19 22:05 PeterK26

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.

roystgnr avatar May 14 '19 14:05 roystgnr

By "worked" I take it that the DTKSolutionTransfer destructor really is there?

roystgnr avatar May 14 '19 14:05 roystgnr

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

PeterK26 avatar May 14 '19 16:05 PeterK26

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:

  1. Install libMesh without DTK or Trilinos enabled
  2. Install Trilinos with DTK (libMesh adapters are enabled)
  3. 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

PeterK26 avatar May 21 '19 00:05 PeterK26

... 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.

roystgnr avatar May 21 '19 01:05 roystgnr

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.

solution_transfer

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.

PeterK26 avatar May 21 '19 17:05 PeterK26

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.

solution_transfer

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.

haxushu avatar Oct 22 '22 12:10 haxushu