[Facets-devel] PETSC ERROR

Barry Smith bsmith at mcs.anl.gov
Thu Jun 4 22:51:37 CDT 2009


    I think there are two distinct issues here:

1)
> some parts of PETSc initialization rely on
> command line, files, and environ vars; and there is no way to
> optionally and programaticaly control them.

    What are these? This is something we can and should fix. Part of  
it may be documentation, for example -log_summary has commands that  
can be used to reproduce the behavior.
If you provide a list of these we can make sure they have function  
interfaces and document the mapping between option and function  
interface.

2)
Some command line (and file) options must be provided at the time of  
PetscInitilize() they are ignored if provided later.

This is true for two possible reasons
a) the code that checks for these provided options (and then does what  
they ask) is internal (not a public interface) and called in  
PetscInitialize() and cannot be called later
b) "possibly" some options, if they were processed after  
PetscInitialize(), would cause crashes or bad stuff.

a- We could make the parseandprocessoptions code a public function  
that could be called later (as well as being called as it is now in  
PetscInitialize()). We would have to have some mechanism to make sure  
it doesn't reprocess stuff it already did. And how about undoing  
previously done conflicting options?
b- We could try to clean up the options so that all of them could be  
set later. Maybe there will always be some that can only be used in  
initialize. For example -malloc_debug and changing the malloc/free  
routines later is likely to always be a problem because it has to be  
consistent during the entire run. Maybe we need to organize the  
startup options into two sets: those that must be used at initialize  
and those that can be used later?

    Is this summary an accurate starting point?

    Barry



On Jun 4, 2009, at 10:32 PM, Lisandro Dalcin wrote:

> On Thu, Jun 4, 2009 at 11:08 PM, Barry Smith<bsmith at mcs.anl.gov>  
> wrote:
>>
>>   I agree with Matt here. If we decomposed in then the initial
>> initialization would setup certain things and the next initialize  
>> (depending
>> on options) would have to decompose the exact same things before  
>> setting
>> another way.
>>
>>   Lisandro,
>>
>>      I do not understand from below what problem you have with them  
>> being
>> together and what advantage you get from them being apart.
>>
>
> Python users not able to do:
>
> from petsc4py import PETSc
> PETSc.setUp(sys.argv) # optional !!
>
> One thing that mpi4py and petsc4py do is automatically manage
> initialization/finalization. It is just ugly in such a dynamic
> language to have to call "Init()"  (and perhaps test for
> "IsInitialized()" ?) before doing anything.
>
> In short, I really do not like the idea of a LIBRARY depending on
> command line arguments for working. In my (probably naive and
> misleading) view, command line arguments are for PROGRAMS, not for
> LIBRARIES.
>
> MPI-1 made that mistake long time ago, I still have to explain to some
> (hopefully few) users still running MPICH1 that they have to use a
> special Python binary to run in parallel. The situation with PETSc is
> not better. Of course, I could manage to somewhat mitigate this issue.
> Please try to remember, you in the past complained about the way
> petsc4py's extension modules were installed and loaded. In part, such
> implementation is for being able to select at runtime different PETSc
> builds (e.g. debug vs. optimized), but other part is having some way
> of passing command line arguments to the Python extension module
> before the call to PetscInitialize().
>
> Fixing this in PETSc is far from trivial, and even perhaps it could
> not be done or it is not worth it. But I would like to know if all you
> acknowledge the issue: some parts of PETSc initialization rely on
> command line, files, and environ vars; and there is no way to
> optionally and programaticaly control them.
>
> ---
>
> -- 
> 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




More information about the petsc-dev mailing list