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