<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 9:23 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"><div class="HOEnZb"><div class="h5">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> On Fri, Mar 16, 2018 at 6:25 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Fri, Mar 16, 2018 at 2:20 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>> ><br>
>> >> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> >><br>
>> >> > On Fri, Mar 16, 2018 at 1:27 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>> >> ><br>
>> >> >> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> >> >><br>
>> >> >> > On Fri, Mar 16, 2018 at 1:17 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>><br>
>> wrote:<br>
>> >> >> ><br>
>> >> >> >> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> >> >> >><br>
>> >> >> >> > I agree. We should remove all code (about 2/3 of it) which does<br>
>> a<br>
>> >> >> >> > hierarchy of communicating dicts (the original design). That<br>
>> would<br>
>> >> >> >> > make everything simple. No threads, no parents, etc. We leave<br>
>> in<br>
>> >> the<br>
>> >> >> >> > help the way we want it, types for args, etc. One thing its<br>
>> notably<br>
>> >> >> >> > missing, and that PETSc Options are missing, is listing the<br>
>> thing<br>
>> >> that<br>
>> >> >> >> > set the option (default, command line, code, env).<br>
>> >> >> >><br>
>> >> >> >> Does RDict even need to be persistent? Who all reads it? I<br>
>> wonder<br>
>> >> if<br>
>> >> >> >> an existing human-readable file would be sufficient instead?<br>
>> >> >> >><br>
>> >> >> ><br>
>> >> >> > I think we should persist the entire set of options used to<br>
>> configure<br>
>> >> for<br>
>> >> >> > later<br>
>> >> >> > interrogation, however we have not done that much so far.<br>
>> >> >><br>
>> >> >> CONFIGURE_OPTIONS is written to petscvariables and printed by make<br>
>> info.<br>
>> >> >> I think fewer duplications is desirable.<br>
>> >> >><br>
>> >> ><br>
>> >> > This gets into a separate discussion. I think Python info is more<br>
>> useful<br>
>> >> > since its<br>
>> >> > directly visible to scripts we might write.<br>
>> >><br>
>> >> Just call your Python parsing function.<br>
>> ><br>
>> ><br>
>> > Parse a makefile to get info? This is too convoluted for my first choice.<br>
>> ><br>
>> ><br>
>> >> But this gets back to my earlier question: who needs to read RDict.db<br>
>> and<br>
>> >> for what purpose?<br>
>> >><br>
>> ><br>
>> > 1) We read this to get the configure modules during install and other<br>
>> post<br>
>> > configure operations.<br>
>> ><br>
>> > 2) I would like us to read RDict.db to get the original configure<br>
>> > environment<br>
>><br>
>> The problem is that RDict.db is opaque<br>
><br>
><br>
> This seems to be a normative characterization. I think the make variables<br>
> are<br>
> "dead" because its hard to make use of them in scripting.<br>
><br>
><br>
>> and some people edit<br>
>> petscvariables and/or petscconf.h to work around weird issues.<br>
><br>
><br>
> Awful. We should not encourage this. It should flow from the top.<br>
<br>
</div></div>Cray and others have admitted to doing this for as long as I've used<br>
PETSc. It's possible to discourage it without setting land mines.</blockquote><div><br></div><div>I guess my attitude is that most people using PETSc attempt to work within the</div><div>structures setup to use it. Cray people seem not to give a fuck and just change</div><div>stuff willy nilly until it works for them. Thats fine. We can't stop them, but I am</div><div>not motivated to enable them either.</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"><span class=""><br>
>> We can't<br>
>> practically get rid of petscvariables without abandoning make.<br>
>><br>
><br>
> The aim should not be to get rid of them, but rather to have them be read<br>
> only.<br>
<br>
</span>Good luck with that.<br>
<span class=""><br>
>> It's also frustrating to debug because the names used in Python may not<br>
>> match the names used in human-readable output,<br>
><br>
><br>
> Changing this is trivial.<br>
<br>
</span>Hooray!<br>
<span class=""><br>
> Matt<br>
><br>
><br>
>> and that also prevents<br>
>> grepping to find unused variables.<br>
>><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their<br>
> experiments is infinitely more interesting than any results to which their<br>
> experiments lead.<br>
> -- Norbert Wiener<br>
><br>
</span>> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~<wbr>knepley/</a> <<a href="http://www.caam.rice.edu/~mk51/" rel="noreferrer" target="_blank">http://www.caam.rice.edu/~<wbr>mk51/</a>><br>
</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>