On Mon, Aug 25, 2008 at 1:22 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote: > On Mon, Aug 25, 2008 at 1:08 PM, Matthew Knepley <knepley at gmail.com> wrote: >> I would still maintain that PETSC_COMM_WORLD is the correct default. There >> are better paradigms for embarassingly parallel operation, like Condor. PETSc >> is intended for parallel, domain decomposition runs. > > Yes, you are completelly right. But I believe that many people still > use PETSc in a sequential way just because PETSc is full featured, > well designed, easy to learn, etc. So, despite PETSc being intended > for parallel, domain decomposition applications, many people are going > to use it for sequential apps and embarassingly parallel operations.
I agree that people will do this, I just don't agree that it should be the default. > To be honest, I've never looked too much at paradigms like Condor. But > using them implies to learn yet another framework. Another anecdote: a > guy sent me a mail with questions about mpi4py for solving a > embarassingly parallel problems. I asked why he was trying to use such > a "heavy weight" approach. And then he answered he was tired of the > complications and performance of using a Grid-based approach, and that > 'mpiexec' a Python script with some coordinating MPI calls was far > easier to setup, extend, and maintain and had better overall running > times than submitting jobs to "The Grid". That is my experience with grid software as well. However, in the particular case of Condor, I disagree. It is fairly easy to setup and has great features like fault tolerance, automatic migration and balancing, that make it much more useful that just MPI. Matt >> On Mon, Aug 25, 2008 at 10:54 AM, Lisandro Dalcin <dalcinl at gmail.com> >> wrote: >>> 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 >>> >>> >> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which >> their experiments lead. >> -- Norbert Wiener >> >> > > > > -- > 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 > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener