[petsc-dev] PetscOptions defaults after PetscInitialize

[Smith, Barry F.]

> On Apr 22, 2018, at 7: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?

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