[petsc-dev] PetscOptions defaults after PetscInitialize

[Matthew Knepley]

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.

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.

   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/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180422/6f4c0298/attachment.html>