<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 22, 2018 at 8:54 PM, Smith, Barry F. <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Apr 22, 2018, at 7:45 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> <br>
> On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
> "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>
> 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.<br>
> <br>
> I am not for this "before PetcInitialize" strategy at all.<br>
<br>
</span> Why not. It was just stupidity on my part 20 years ago that I didn't think to make the various set options functions callable before PetscInitialize(). Better just to fix that oversight.<br>
<span class=""><br>
> <br>
> However, I do think its far too fat. It initializes everything we can think of without<br>
> giving the user and entry points in to customize it. That is compiler-level user disempowerment.<br>
> <br>
> I would rather see us rearchitect Init() so that you have better control over options, logging,<br>
> CUDA, and all the other initializations hiding in there.<br>
<br>
</span> Make a concrete proposal. "better control" is pretty vague.</blockquote><div><br></div><div>We break up PetscInitialize() into</div><div><br></div><div> - Lightweight initialization, PetscInit(), that does not</div><div> - Process the command line</div><div> - Init logging</div><div> - Init CUDA</div><div> - Do any other package-type inits</div><div> - Inits of the various packages</div><div><br></div><div>So PetscInitialize() would still do the same job. However, people wanting to</div><div>do special processing can call the lightweight init, then configure the packages</div><div>as they please, and then the package init loop.</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">
> <br>
> Matt<br>
> <br>
> > 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>
> <br>
> <br>
> <br>
> -- <br>
> 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<br>
> <br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~<wbr>knepley/</a><br>
<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>