> On Apr 22, 2018, at 7: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?
I forgot about that. > Or > PetscOptionsInsertFile somehow caches the file contents without using > PetscMalloc and broadcasts it after reaching PetscInitialize? That > seems a bit crazy. Maybe have use of pre-PetscInitialize() PetscOptionsInsertFile() cache the __file name(s)__ and then have PetscInitialize() loop over the cached filenames and load those options using simple MPI and PetscOptionsSetValue() before processing the command line etc Post-PetscInitialize() use of PetscOptionsInsertFile() would remain the same as today. We'd still need a stripped down version of PetscOptionsInsertFile(). Your proposed route allows bad decisions made years ago to dictate a bad user API forever. I don't like that. Barry > >> 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?
