On Mon, Aug 25, 2008 at 8:13 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 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?
Yes, you can make it a 'property'. Matt > 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 >> > > -- 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
