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

build failure: multiple definition of `void Xpetra::Jacobi #60

Closed
nschloe opened this issue Dec 18, 2015 · 3 comments
Closed

build failure: multiple definition of `void Xpetra::Jacobi #60

nschloe opened this issue Dec 18, 2015 · 3 comments

Comments

@nschloe
Copy link
Member

nschloe commented Dec 18, 2015

The current master fails to build with

[...]
Wl,-Bdynamic ../../kokkos/algorithms/src/libtrilinos_kokkosalgorithms.so.12.5 ../../kokkos/core/src/libtrilinos_kokkoscore.so.12.5 
CMakeFiles/trilinos_stokhos_muelu.dir/sacado/kokkos/pce/muelu/MueLu_SaPFactory_UQ_PCE_Serial.cpp.o: In function `Xpetra::TpetraCrsGraph<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >::getMap() const':
/«PKGBUILDDIR»/packages/stokhos/src/sacado/kokkos/pce/Sacado_UQ_PCE.hpp:145: multiple definition of `void Xpetra::Jacobi<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >(double, Xpetra::Vector<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > const&, Xpetra::Matrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > const&, Xpetra::Matrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > const&, Xpetra::Matrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >&, bool, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

Full details (including configuration) at Launchpad.

@etphipp
Copy link
Contributor

etphipp commented Dec 18, 2015

@trilinos/xpetra

@trilinos/muelu

I see what the problem is. Xpetra_IteratorOps.hpp defines a specialization of Xpetra::Jacobi in the header file:

#if defined(HAVE_XPETRA_EPETRA) && !defined(XPETRA_EPETRA_NO_32BIT_GLOBAL_INDICES)
  template<>
  void Jacobi<double,int,int,EpetraNode>(double omega,
                                         const Xpetra::Vector<double,int,int,EpetraNode> & Dinv,
                                         const Xpetra::Matrix<double,int,int,EpetraNode> & A,
                                         const Xpetra::Matrix<double,int,int,EpetraNode> & B,
                                         Xpetra::Matrix<double,int,int,EpetraNode> &C,
                                         bool call_FillComplete_on_result,
                                         bool doOptimizeStorage,
                                         const std::string & label) {

...

}

which will not work if there is ever more one instantiation of MueLu::SaPFactory. This happens in Stokhos due to the additional instantiations on Stokhos' scalar types, but I believe would also arise in MueLu if it were instantiated on more than one node type. The file needs to be changed to declare the specialization in the header file and put the definition in a cpp file.

Xpetra/MueLu devs: do you ever test with more than one node instantiation?

-Eric

@aprokop
Copy link
Contributor

aprokop commented Dec 18, 2015

This was fixed in the morning in 2237238.

@etphipp Yes, we do test with multiple nodes. This particular issue was not present for multiple nodes, but arose in one particular configuration for ETI.

@nschloe
Copy link
Member Author

nschloe commented Dec 18, 2015

@aprokop Can you close the issue then?

@aprokop aprokop closed this as completed Dec 18, 2015
kddevin added a commit that referenced this issue Feb 17, 2016
when many zero-weight dots exist.  This
version moves zero-weight dots if any dots are being moved.
These changes (1) resolve infinite loop problems seen in fuego, and
(2) correct a reported bug in which non-rectilinear domains were
returned when a problem had zero-weighted elements and
rcb_rectilinear_blocks=1.

zoltan:  These changes change ch_bug and ch_onedbug answers by assigning
zero-weighted object #60 to a different part than before.

zoltan2:  added two test problems to verify that the zoltan changes
work for rectilinear blocks and a fuego-based input.
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