Hello,
I am looking for the piece of MPI/ParMetis code that distribute the
Tetrahedral Mesh
over the processors and also the associated unknown to "update".
Please note that I am looking for the low level ones coded in Libmesh
and not
the high level ones.
Could you please let me know where I could find those ?
Thank you very much for your help
Tahar
--------------------------------------------
T. Amari
Centre de Physique Theorique
Ecole Polytechnique
91128 Palaiseau Cedex France
tel : 33 1 69 33 47 53
fax: 33 1 69 33 30 08
email: <mailto:[EMAIL PROTECTED]>
URL : http://www.cpht.polytechnique.fr/cpht/amari
Le 18 nov. 07 à 14:32, Benjamin Kirk a écrit :
You can't mix stdio.h (which I think g++ uses internally) with
MPICH2's C++ bindings, because for some reason the MPI-2 C++ binding
reuses macro names from the C standard. We used to have a workaround
for this in libMesh, but it caused its own problems, so since we only
use the MPI C bindings anyway we now only link against MPICH with C++
bindings turned off.
Yeah -- Unfortunately, the MPI C++ interface is really not very
useful. It
puts everything in an MPI namespace, but that is about it.
Besides, we use
PETSc/Parmetis,both of which require MPI_*** in the global
namespace anyway.
I prefer using the C API wrapped as it is in Parallel:: anyway - I
think
Roy's use of templates and function overloading here is much more
useful
than the C++ MPI interface. Also, since the C++ ABI is not entirely
standard, using the C++ MPI ivterface would likely further limit
the choice
of compilers when using e.g. Vendor-supplied MPI on supercomputers.
Because ICES keeps f77 around linked to g77 from gcc 3.2, the libMesh
configure script tries to link using library paths from the old
version of gcc; this confuses the linker when called from g++:
"warning: libstdc++.so.6, needed by
/ices/roystgnr/software/libmesh/lib/x86_64-unknown-linux-gnu_dbg/
libmesh.so,
may conflict with libstdc++.so.5" Telling configure to use the newer
gfortran instead fixed this.
I'd say the f77/gfortran confusion counts as a bug in our configure
scripts, but I'm not sure what we could do to fix it other than
detect
and error out when we saw such a version conflict. Hopefully we
won't
have too many people trying to install on systems where the default C
compiler is GCC4 and the default Fortran compiler is GCC3.
This one is a little touchy and has been an issue for a while...
The crux
of the problem is that we check for 'AC_PROG_F77' which checks for a
Fortran-77 capable compiler. Since PETSc only requires Fortran-77
support
this is the right thing to do, since libMesh only needs to be
capable of
linking to f77 programs. ./configure searches for a number of
compilers in
this case, and it looks for g77 before gfortran. Again, this is the
right
thing to do.
'AC_PROG_FC' is one solution, but this looks for a Fortran-90+
compiler
which we really don't need.
Since this is pretty gcc/g77 specific, we should be able to detect
a gcc/g77
version mismatch, look for gfortran, and then abort if unsuccessful.
-Ben
----------------------------------------------------------------------
---
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
