[Facets-devel] PETSC ERROR

[Satish Balay]

There is another alternative possible [similar to how PETSC_COMM_WORLD
can be set by user.]

i.e.

PETSC_COMM_WORLD=comm;
PetscIntialize()..

Since we just can't just set a char avariable - esp from fortran, we -
we would have to do this with a function:

PetscSetOptionalOptionsFile("petscopt") [stash internally in some global variable
                                          PETSC_OPTIONS_FILE]
PetscInitialize() ---> [process PETSC_OPTIONS_FILE in the same way as ~/.petscrc]

Satish

On Thu, 4 Jun 2009, Barry Smith wrote:

> 
>   Matt,
> 
>     The problem is more general than what FACETS want.
> 
>     Say Joe would like to write an application that uses an optional options
> file if it is there but runs fine without the optional file.  As Satish points
> out this is exactly what .petscrc is.
> 
>     If that optional file contains PETSc startup options like -malloc_debug
> etc etc  then this is cumbersome in PETSc.  The application code would have to
> see if the file exists (in parallel) and then call PetscInitialize() with or
> without that filename depending on when it exists.
> 
>     One solution is to have PETSc always treat the file you list as optional;
> I decided NOT this many years ago because if __I__ call a function with a file
> argument I want it to generate an error if it does not exist. Much later we
> changed PetscOptionsInsertFile() to take an additional argument indicating the
> file existence is optional. This solves the optional file sometimes but not if
> the file is going to contain PETSc startup options.  I also debated allowing a
> filename like "optional:myfilename" but that is just a cheap trick to avoid
> changing the calling sequence and not worthy of PETSc.
> 
>   The "correct" solution is adding an additional require argument, yucky
> though it is.
> 
>    Barry
> 
> We could go the GNU route and have them use the environmental variable
> PETSC_OPTIONS to pass in their arguments :-)
> 
> 
> On Jun 4, 2009, at 4:38 PM, Matthew Knepley wrote:
> 
> > On Thu, Jun 4, 2009 at 4:15 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> > On Thu, 4 Jun 2009, Matthew Knepley wrote:
> > 
> > > On Thu, Jun 4, 2009 at 3:37 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> > > 
> > > > Barry/Matt,
> > > >
> > > > Should we make optfile in PetscIntialize(optfile) optional?
> > > 
> > > 
> > > Why would the user give an argument for optfile, but not intend it to be
> > > found?
> > 
> > Normally command line options is the way to pass in optional flags to
> > a petsc binary. In this application - command line options are not
> > possible [due to python/other packages that control main] - hence an
> > PetscIntialize("petscopt") is used to pass in equivalent optional
> > flags.
> > 
> > 
> > Also In this code - PETSc [solver] usage is optional. I guess there
> > are 2 ways of implementing this.
> > 
> > The first is to always call PetscInitialize()/Finalize() - but
> > optionally use PETSc solvers. [in this case optfile should be
> > optional]
> > 
> > I have no idea what you mean here. Why does optfile have to be an optional
> > argument?
> > That makes no sense at all. You provide an argument, but only want it used
> > sometimes?
> > DONT PROVIDE IT if it should not be used.
> > 
> >  Matt
> > 
> > 
> > The other mode is to avoid PetscIntialize()/Finalize() - when
> > non-petsc solvers are selected.  [but this means more complicated
> > options check - before PetscIntialize()/MPI_Init() is called. The code
> > currently tries to do this - ocassionaly errors such as this pop-up]
> > 
> > 
> > I guess Ideally - the optional_flag should be exposed all the way to
> > PetscInitialize() - so the user can make the choice if this opt-file
> > is optional or required..
> > 
> > Satish
> > 
> > 
> > 
> > -- 
> > 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
>