[petsc4py] What should be the 'default' communicator?

Lisandro Dalcin dalcinl at gmail.com
Mon Aug 25 10:54:10 CDT 2008


After working hard on mpi4py, this week I'll spend my time cleaning-up
and adding features to the new Cython-based petsc4py. Then, I'll be
asking questions to this list requesting for advise.

In all calls that create new PETSc objects, I've decided to make the
'comm' argument optional. If the communicator is not passed,
PETSC_COMM_WORLD is currently used. This is the approach PETSc uses in
some C++ calls implemented through PetscPolymorphicFunction().

But now I believe that is wrong, and that PETSC_COMM_SELF should be
the default. Or perhaps even better, I should let users set the
default communicator used by petsc4py to create new (parallel)
objects.

An anecdote: some time ago, a petsc4py user wrote a sequential code
and created objects without passing communicator arguments, next he
wanted to solve many of those problems in different worker processes
in a "ambarrasingly parallel" fashion and collect results at the
master process. Of course, he run into trouble. Then I asked him to
initialize PETSc in such a way that PETSC_COMM_WORLD was actually
PETSC_COMM_SELF (by setting the world comm before PetscInitalize()).
This mostly works, but has a problem: we have lost the actual
PETSC_COMM_WORLD, so we are not able to create a parallel object after
PetscInitialize().

Any thoughts?


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594




More information about the petsc-dev mailing list