[petsc-dev] PetscOptions defaults after PetscInitialize

[Smith, Barry F.]

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

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