On Aug 25, 2008, at 5:40 PM, Lisandro Dalcin wrote: > On Mon, Aug 25, 2008 at 6: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, sorry, I do not completely understand your comments. All my > concern about this is only relevant to petsc4py and not core PETSc. > With that in mind, I prefer to "hide" PETSC_COMM_DEFAULT from users, > and ask them to call the getter/setter routines. You know: in Python, > changing module-level globals is a bit unsafe: a user could do: > > from petsc4py import PETSc > PETSc.COMM_DEFAULT = None # or watever > > and then latter get a failure. Furthermore, the setter can be in > charge of all the relevant error checking: the comm have to actually > be an instance of 'PETSc.Comm' type, and its comunicator cannot be the > MPI_COMM_NULL. > Can you not overload the assignment = to automatically call whatever fancy setter you want to use? Then you get the simplicity I crave and the safety you desire?
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 >>> >> >> > > > > -- > 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 >