On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <j...@jedbrown.org> wrote:
> "Smith, Barry F." <bsm...@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 <j...@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/>