<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">"Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
<br>
>   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?<br>
<br>
</span>You want every rank to open the file independently?  Or<br>
PetscOptionsInsertFile somehow caches the file contents without using<br>
PetscMalloc and broadcasts it after reaching PetscInitialize?  That<br>
seems a bit crazy.</blockquote><div><br></div><div>I am not for this "before PetcInitialize" strategy at all.</div><div><br></div><div>However, I do think its far too fat. It initializes everything we can think of without</div><div>giving the user and entry points in to customize it. That is compiler-level user disempowerment.</div><div><br></div><div>I would rather see us rearchitect Init() so that you have better control over options, logging,</div><div>CUDA, and all the other initializations hiding in there.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>    Barry<br>
><br>
><br>
>> On Apr 22, 2018, at 5:54 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>> <br>
>> For users that read their own configuration files and/or choose<br>
>> PetscOptionsInsertFile after PetscInitialize, we don't have a good way<br>
>> to avoid overwriting PETSC_OPTIONS or command-line options.  The user<br>
>> could manually find argv and the environment variable, but that's a poor<br>
>> abstraction.  Should PetscOptionsInsertFile learn how to behave so as to<br>
>> add new entries to the options database, but not supersede any that<br>
>> already exist?<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>