libMesh: A C++ Finite Element Library

On Tue, 16 Mar 2010, Edouard Oudet wrote:

> I am trying to link matlab and libmesh. I wrote a very stupide mex file
> "mex_loadlibmesh.cxx" (see below) to test the inital call of libmesh
> from matlab. The problem is that my mex file never stop ! I suspect of
> course a problem related to MPI but I have no idea how to fix this.

I don't know enough about Matlab/C++ integration to be much help, but
some suggestions:

Build libMesh without MPI?  Some MPI stacks absolutely require you to
run them with mpirun/mpiexec to set up the environment and command
line options; you might have one of those.

Another, possibly related problem: your function initializes libMesh
when the LibMeshInit object is created, but then it terminates libMesh
when the LibMeshInit object goes out of scope.  That's probably not
what you want to do, right?  Create the LibMeshInit object on the heap
(with new) instead of the stack and then destroy it manually when
you're done.
---
Roy

On Tue, 16 Mar 2010, Edouard Oudet wrote:

> I made some progresson my problem of linking and I will report on the mailing 
> list when it is completely OK (if it happens...).

Please do, thanks.

> Actually there is no one but many problems with that linking :
>
> - first of all in src/base/libmesh.C the two following lines
>
>  if (!libMesh::on_command_line ("--sync-with-stdio"))
>       std::ios::sync_with_stdio(false);
>
> have to be commented or matlab does not go out from the mex file.

Interesting.  Someone (Ben?) found out that turning off synchronization
of C and C++ output gives a speed improvement, so we do that by
default; I had presumed that when you actually do mix C/C++ output (as
you would by interleaving Matlab and libMesh output) the result might
be a bit garbled, but I didn't realize it might hang the code.

There's a few libMesh command-line-only options like this that we
ought to make easier to set from source code, for situations like
yours where adding them on the command line might be impossible or
might confuse other software.  The best you can do right now without
modifying library code is to create a modified argv/argc.

> As you suggested  I am trying to use libmesh without MPI. I compiled PETSC 
> and SLEPC with the option --with-mpi=0 and everything goes well (small tests 
> work fine). When compiling libmesh I have somme problems. Actually the 
> configuration step does not work (see below for the details) :  ./configure 
> --enable-slepc  --enable-petsc --disable-mpi. But perhaps this sequence of 
> option is not allowed ?

It's not currently allowed; configure assumes that if you're using
PETSc you're also using MPI, even if it's a "null" MPI stack.
---
Roy

On Tue, 16 Mar 2010, Edouard Oudet wrote:

> One last question : do you think it would be  a hard task to adapt the code 
> to options --enable-petsc --disable-mpi ?

Not sure.  It wouldn't touch most of the library, but there's
definitely fixes needed in configure.in, libmesh_common.h libmesh.C,
and petsc.m4.  Possibly extensively in petsc_*.C and petsc_*.h as
well.  I don't even know what CHKERRABORT is supposed to do if PETSc
is configured --with-mpi=0 and MPI_Abort isn't available.

I'll take a quick crack at it this afternoon, but it's not high on my
priority list, so unless it turns out to be an easy fix you'll be
stuck doing it yourself.
---
Roy

On Tue, 16 Mar 2010, Roy Stogner wrote:

> I'll take a quick crack at it this afternoon, but it's not high on my
> priority list, so unless it turns out to be an easy fix you'll be
> stuck doing it yourself.

The fixes were pretty easy; testing a bunch of different
configurations was not.  But it looks like the libMesh svn HEAD now
works with PETSc enabled and MPI disabled.  Give it a try.

To everyone else: this seemed like a simple change, but Roy editing m4
files, finding new ways to snoop PETSc config files, and making
low-level changes are all risky things.  Be paranoid when updating and
let me know ASAP if there's any weirdness.  I've put in a bunch of
minor changes lately, but the tricky parts of this one are all in
r3742 so we can revert in one stroke if necessary.
---
Roy

On Tue, 16 Mar 2010 15:50:50 -0500 (CDT), Roy Stogner <roystgnr@...> wrote:
> 
> On Tue, 16 Mar 2010, Edouard Oudet wrote:
> 
> > One last question : do you think it would be  a hard task to adapt the code 
> > to options --enable-petsc --disable-mpi ?
> 
> Not sure.  It wouldn't touch most of the library, but there's
> definitely fixes needed in configure.in, libmesh_common.h libmesh.C,
> and petsc.m4.  Possibly extensively in petsc_*.C and petsc_*.h as
> well.  I don't even know what CHKERRABORT is supposed to do if PETSc
> is configured --with-mpi=0 and MPI_Abort isn't available.

As you probably know, --with-mpi=0 just means that PETSc uses a mock
implementation (mpiuni, a slightly incomplete serial implementation).
In this case, MPI_Abort() is still defined and just calls abort().

Jed

Dear Roy,

Thank you very much for your help. I successfully compiled the r3742 
without mpi and with petsc/slepc support.
Unfortunately, when running from matlab my stupide mex file 
"mex_loadlibmesh.cxx"
(see my previous post 
http://sourceforge.net/mailarchive/message.php?msg_id=4B9F69C3.2020604%40univ-savoie.fr), 

I obtain the following message :

------------------------------------------------------------------------
 >> mex_loadlibmesh
STEP 1
STEP 2
STEP 3
LibMeshInit done
 >> mex_loadlibmesh
STEP 1
[0]PETSC ERROR: --------------------- Error Message 
------------------------------------
[0]PETSC ERROR: You can not initialize PETSc a second time!
[0]PETSC ERROR: 
------------------------------------------------------------------------
[0]PETSC ERROR: Petsc Release Version 3.0.0, Patch 11, Mon Feb  1 
11:01:51 CST 2010
[0]PETSC ERROR: See docs/changes/index.html for recent updates.
[0]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
[0]PETSC ERROR: See docs/index.html for manual pages.
[0]PETSC ERROR: 
------------------------------------------------------------------------
[0]PETSC ERROR: test on a linux-gnu named a175.lama.univ-savoie.fr by 
oudet Wed Mar 17 15:54:34 2010
[0]PETSC ERROR: Libraries linked from 
/home/oudet/C++/Petsc/petsc-3.0.0-p11/linux-gnu-opt/lib
[0]PETSC ERROR: Configure run at Wed Mar 17 15:17:53 2010
[0]PETSC ERROR: Configure options --with-cc="gcc -fPIC" --with-cxx="g++ 
-fPIC" --with-fc="gfortran -fPIC" --with-mpi-compilers=0 --with-shared=0 
--with-dynamic=0 --with-debugging=0 --with-superlu=1 
--download-superlu=1 --with-umfpack=1 --download-umfpack=1 --with-mpi=0 
--download-f-blas-lapack=yes
[0]PETSC ERROR: 
------------------------------------------------------------------------
[0]PETSC ERROR: PetscInitialize() line 485 in src/sys/objects/pinit.c
[0]PETSC ERROR: SlepcInitialize() line 140 in src/sys/slepcinit.c
STEP 2
------------------------------------------------------------------------

and then, matlab session logout !
Does any one has some suggestions to force Petsc/Slepc to stop at the 
end of the first run in that context ?

Best regards, Edouard.
>
> On Tue, 16 Mar 2010, Roy Stogner wrote:
>
>> I'll take a quick crack at it this afternoon, but it's not high on my
>> priority list, so unless it turns out to be an easy fix you'll be
>> stuck doing it yourself.
>
> The fixes were pretty easy; testing a bunch of different
> configurations was not.  But it looks like the libMesh svn HEAD now
> works with PETSc enabled and MPI disabled.  Give it a try.
>
> To everyone else: this seemed like a simple change, but Roy editing m4
> files, finding new ways to snoop PETSc config files, and making
> low-level changes are all risky things.  Be paranoid when updating and
> let me know ASAP if there's any weirdness.  I've put in a bunch of
> minor changes lately, but the tricky parts of this one are all in
> r3742 so we can revert in one stroke if necessary.
> ---
> Roy


-- 
Edouard Oudet : http://www.lama.univ-savoie.fr/~oudet/
Université de Savoie
Laboratoire de Mathématiques (LAMA) UMR 5127
Campus Scientifique
73 376 Le-Bourget-Du-Lac
+33 (0)4 79 75 87 65  (office)
+33 (0)4 79 68 82 06  (home)

On Wed, 17 Mar 2010, Edouard Oudet wrote:

> I obtain the following message :
>
> ------------------------------------------------------------------------
>>> mex_loadlibmesh
> STEP 1
> STEP 2
> STEP 3
> LibMeshInit done
>>> mex_loadlibmesh
> STEP 1
> [0]PETSC ERROR: --------------------- Error Message 
> ------------------------------------
> [0]PETSC ERROR: You can not initialize PETSc a second time!
>
> and then, matlab session logout !
> Does any one has some suggestions to force Petsc/Slepc to stop at the end of 
> the first run in that context ?

To avoid initializing PETSc a second time, I would suggest you avoid
initializing PETSc a second time.  ;-)  What else did you expect a
second initialization call to do?

Create LibMeshInit on the heap with mex_loadlibmesh so it doesn't
destroy at the end, then create a mex_unloadlibmesh to destroy it when
you really are done.
---
Roy