[petsc4py] What should be the 'default' communicator?

[Matthew Knepley]

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