On Apr 22, 2018, at 7:45 PM, Matthew Knepley <[email protected]> wrote:

On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <[email protected]> wrote: "Smith, Barry F." <[email protected]> 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 <[email protected]> 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/