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