I am cool with this. Matt
On Mon, Aug 25, 2008 at 4:48 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > This is fine for me, except I vote against the setter/getter. Just let the > power user access the variable PETSC_COMM_DEFAULT directly. > > Barry > > > On Aug 25, 2008, at 4:43 PM, Lisandro Dalcin wrote: > >> On Mon, Aug 25, 2008 at 6:22 PM, Matthew Knepley <knepley at gmail.com> >> wrote: >>> >>> I agree that people will do this, I just don't agree that it should be >>> the default. >> >> Would you agree with the following: >> >> At petsc4py initialization (and after calling PetscInitialize()), I >> define PETSC_COMM_DEFAULT = PETSC_COMM_WORLD. All parallel PETSc >> objects created through petsc4py use PETSC_COMM_DEFAULT if the >> communicator is not explicitelly passed as an argument. Additionally, >> I expose in petsc4py a getter/setter enabling users to change at ANY >> TIME the default communicator to use. With this approach, the world >> communicator will be default, unless changed by the (power) user. >> >> >> >>>> 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 >>> >>> >> >> >> >> -- >> 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
