[petsc-dev] PetscOptions defaults after PetscInitialize

[Matthew Knepley]

On Sun, Apr 22, 2018 at 8:54 PM, Smith, Barry F. <bsmith at mcs.anl.gov> wrote:

> > On Apr 22, 2018, at 7:45 PM, Matthew Knepley <knepley at gmail.com> wrote:
> >
> > On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <jed at jedbrown.org> wrote:
> > "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> >
> > >   Yuck, I think a far better user API is that PetscOptionsInsertFile()
> be callable before PetscInitialize(). The problem is that people have
> shoveled so much post-PetscInitialize() code into  PetscOptionsInsertFile()
> over the years that stripping it all out would be painful. Maybe get a
> simplier pre- 2005 version of the routine and strip out the
> post-PetscInitialize() material?
> >
> > You want every rank to open the file independently?  Or
> > PetscOptionsInsertFile somehow caches the file contents without using
> > PetscMalloc and broadcasts it after reaching PetscInitialize?  That
> > seems a bit crazy.
> >
> > I am not for this "before PetcInitialize" strategy at all.
>
>    Why not. It was just stupidity on my part 20 years ago that I didn't
> think to make the various set options functions callable before
> PetscInitialize(). Better just to fix that oversight.
>
> >
> > However, I do think its far too fat. It initializes everything we can
> think of without
> > giving the user and entry points in to customize it. That is
> compiler-level user disempowerment.
> >
> > I would rather see us rearchitect Init() so that you have better control
> over options, logging,
> > CUDA, and all the other initializations hiding in there.
>
>    Make a concrete proposal. "better control" is pretty vague.


We break up PetscInitialize() into

  - Lightweight initialization, PetscInit(), that does not
    - Process the command line
    - Init logging
    - Init CUDA
    - Do any other package-type inits
  - Inits of the various packages

So PetscInitialize() would still do the same job. However, people wanting to
do special processing can call the lightweight init, then configure the
packages
as they please, and then the package init loop.

   Matt


> >
> >    Matt
> >
> > >    Barry
> > >
> > >
> > >> On Apr 22, 2018, at 5:54 PM, Jed Brown <jed at jedbrown.org> wrote:
> > >>
> > >> For users that read their own configuration files and/or choose
> > >> PetscOptionsInsertFile after PetscInitialize, we don't have a good way
> > >> to avoid overwriting PETSC_OPTIONS or command-line options.  The user
> > >> could manually find argv and the environment variable, but that's a
> poor
> > >> abstraction.  Should PetscOptionsInsertFile learn how to behave so as
> to
> > >> add new entries to the options database, but not supersede any that
> > >> already exist?
> >
> >
> >
> > --
> > 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
> >
> > https://www.cse.buffalo.edu/~knepley/
>
>


-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180422/08eec324/attachment.html>