Hi Luca:
Ok, I did not realize that you could do that with PETSc, so I
downloaded Metis-4.0 and followed the instructions on the deal.II
webpage to remove the declarations in proto.h of srand48(), drand48(),
and log2. I then get this compile error (from the METIS compilation):
util.c:512: error: conflicting types for ‘__log2’
/usr/include/bits/mathcalls.h:145: note: previous declaration of
‘__log2’ was here
so I tried removing the actual code from util.c of the log2 function
(hey, I getting desperate!), compiled METIS without problems, compiled
deal.II with METIS without problems, but then when I try and compile
example 17 I get his error at linking:
/home/nasser/deal.II/lib/liblac.g.so: undefined reference to `__log2'
If I can get this worked out and run the examples, I write up
instructions to put on the website to avoid this from happening with
someone else, but I am not sure how to get rid of this last linking
error.
Nasser
Luca Heltai wrote:
1) Once the correct compilers are used, I run
"mpiexec -np 2 ./step-17" and get an error that METIS is not installed.
I installed libparmetis-dev and try and try to compile, but get a huge
number of compile errors regarding conflicting declarations of many
MPI::FUNCTIONs. Before I go any farther with this, it occured to me
that should I be using the serial version of METIS, correct?
As far as I know, we do not use parmetis. Metis 4.0 is the one that we
support, and, at least on my configurations, this works.
2) Shouldn't the configure script
automagically set CC,CXX,and F77 to the MPI wrappers if PETSc is
specified (since PETSc requires MPI)?
Not necessarily. You can compile PETSc without mpi...
3) I still do not understand why calling the
MPI functions when deal.II is not compiled to support MPI does not
result in an error state. As-is, there is zero indication to the user
that he/she is just running many individual copies of the program,
other than a crash and the subsequent wasted time of trying to debug.
The MPI mechanism allows you to call ANY progran within the MPI
framework (I, for example, use mpi to parallelize also my bash scripts
and create movies with povray in parallel). In general, when you call
mpirun, you are simply making sure that multiple copies of the same
program are run, with environmental variables set up in a correct
manner (this depends on the mpi library you chose, but they all work
the same way).
What the program does with the environmental variables, it is the
programmer responsability, and tipically it is taken care of by the
mpi.h include file. If you compile deal without using mpicxx, mpicc and
mpif77, then deal.II will simply ignore those variables (it will not
include mpi.h, and will provide reasonable default functions for all
those classes which actually need to know about processes and ids...).
There are many implementations of mpi. It would not be feasible for
deal.II to check wether we were called from within mpirun or not at run
time (besides being more expensive, OpenMPI uses different environment
variables than mpich, for example, just to name 2 implementations...).
I think it makes more sense to configure things properly at the
beginning, and simply trust murphy's law...
:)
Luca.
|
