From: Lorenzo Z. <za...@ai...> - 2014-01-20 17:09:28
|
Hello, Our IT team developed a new procedure for installing libmesh on our iMac machines, so that petsc, slepc, glpk, and eigen are called from the macports that are controlled by them. The procedure - here below - works fine, I think the girl called Vera wrote here to come up with it. There's something weird though. In order to run the examples - or any other code - after the installation, the assertion in the main file libmesh_example_assert(libMesh::default_solver_package() == PETSC_SOLVERS, "--enable-petsc"); has to be commented out, since it would otherwise fail. After doing that, petsc works fine, despite the assertion. When it comes to nonlinear solvers though (e.g. miscellaneous ex7), the situation is more problematic since the assertion that fails lies in nonlinear_solver.C: #if defined(LIBMESH_HAVE_PETSC) || defined(LIBMESH_HAVE_NOX) … #else // LIBMESH_HAVE_PETSC || LIBMESH_HAVE_NOX template <typename T> AutoPtr<NonlinearSolver<T> > NonlinearSolver<T>::build(sys_type&, const SolverPackage) { libMesh::err << "ERROR: libMesh was compiled without nonlinear solver support" << std::endl; libmesh_not_implemented(); } #endif and the error ends the program. Even if I do #define LIBMESH_HAVE_PETSC inside the main file, I assume it gets undefined somewhere, because I get the error anyway. Do you think there is a solution for this? Thanks a lot, Lorenzo The installation procedure: # cd ~/Desktop # git clone git://github.com/libMesh/libmesh.git libmesh_root # cd libmesh_root # mkdir build # mkdir installed # cd build # ../configure --prefix=/home/<NAME>/Desktop/libmesh_root/installed --with-glpk-include=/usr/local/macports108/include --with-glpk-lib=/usr/local/macports108/lib --with-eigen-include=/usr/local/macports108/include/eigen3 --with-hdf5=/usr/local/macports108 --enable-petsc --enable-slepc --enable-mpi --enable-examples CXX=openmpicxx CC=openmpicc FC=openmpif90 F77=openmpif90 CXXFLAGS=-I/opt/X11/include LDFLAGS=-L/opt/X11/lib # make -j2 # make install # make check |
From: John P. <jwp...@gm...> - 2014-01-20 17:34:40
|
On Mon, Jan 20, 2014 at 9:34 AM, Lorenzo Zanon <za...@ai...>wrote: > Hello, > > Our IT team developed a new procedure for installing libmesh on our iMac > machines, so that petsc, slepc, glpk, and eigen are called from the > macports that are controlled by them. The procedure - here below - works > fine, I think the girl called Vera wrote here to come up with it. > > There's something weird though. In order to run the examples - or any > other code - after the installation, the assertion in the main file > > libmesh_example_assert(libMesh::default_solver_package() == PETSC_SOLVERS, > "--enable-petsc"); > > has to be commented out, since it would otherwise fail. After doing that, > petsc works fine, despite the assertion. > If this assertion fails, I'm pretty sure it means PETSc wasn't found during libmesh installation, so I'm a little confused how you know it "works fine". For example, do you know it's not falling back on Laspack solvers? -- John |
From: Lorenzo Z. <za...@ai...> - 2014-01-22 12:41:56
|
On Jan 20, 2014, at 6:34 PM, John Peterson <jwp...@gm...> wrote: > > > > On Mon, Jan 20, 2014 at 9:34 AM, Lorenzo Zanon <za...@ai...> wrote: > Hello, > > Our IT team developed a new procedure for installing libmesh on our iMac machines, so that petsc, slepc, glpk, and eigen are called from the macports that are controlled by them. The procedure - here below - works fine, I think the girl called Vera wrote here to come up with it. > > There's something weird though. In order to run the examples - or any other code - after the installation, the assertion in the main file > > libmesh_example_assert(libMesh::default_solver_package() == PETSC_SOLVERS, "--enable-petsc"); > > has to be commented out, since it would otherwise fail. After doing that, petsc works fine, despite the assertion. > > If this assertion fails, I'm pretty sure it means PETSc wasn't found during libmesh installation, so I'm a little confused how you know it "works fine". For example, do you know it's not falling back on Laspack solvers? > Yes, you are right, it's actually using Laspack. That's why the examples requiring only linear solver run, whereas the others don't. Then the installation procedure is wrong. Thanks! Lorenzo |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-22 13:59:43
|
On Jan 20, 2014, at 10:34 AM, Lorenzo Zanon <za...@ai...> wrote: > The installation procedure: > > # cd ~/Desktop > # git clone git://github.com/libMesh/libmesh.git libmesh_root > # cd libmesh_root > # mkdir build > # mkdir installed > # cd build > # ../configure > --prefix=/home/<NAME>/Desktop/libmesh_root/installed > --with-glpk-include=/usr/local/macports108/include > --with-glpk-lib=/usr/local/macports108/lib > --with-eigen-include=/usr/local/macports108/include/eigen3 > --with-hdf5=/usr/local/macports108 > --enable-petsc > --enable-slepc > --enable-mpi > --enable-examples > CXX=openmpicxx CC=openmpicc FC=openmpif90 F77=openmpif90 > CXXFLAGS=-I/opt/X11/include LDFLAGS=-L/opt/X11/lib Provided PETSC_DIR and PETSC_ARCH are properly set, this should do the trick. Of course have a look at the printed summary to see if libMesh found PETSc, which I think we've resolved is not the case. You can then look in config.log for things like 'petsc.h' to find the bits where it tested for PETSc, and failed. That'll usually uncover the issue. If not, send the config.log directly to me (and other interested parties) as the mailing list filter will usually strip it due to size. -Ben |