<div dir="ltr"><div dir="ltr">On Sun, Jan 22, 2023 at 1:06 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div>  That makes incrementally adding new options to an existing object difficult, since each call to setFromOptions() screws up previous calls.<div><br></div><div>We already have<div><br></div><div>-ksp_monitor_cancel</div><div>-ksp_converged_reason_view_cancel</div></div></div></blockquote><div><br></div><div>Let me address it another way. If I understand correctly, what happens currently is that at each ViewFromOptions() call, the database is inspected and if a *_view is found, then the view is executed. So when you replace the database, if this option is not found then nothing happens. This seems to satisfy a kind of options locality. If instead we make some options sticky, like -ksp_view, so that once given they never expire, this would make the code exceedingly hard to reason about, especially if options are set deep inside something, before a user is knowingly doing things. This does not sound like the right model to me.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><blockquote type="cite"><div>On Jan 22, 2023, at 12:45 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">On Sat, Jan 21, 2023 at 4:34 PM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  If I run KSPSetFromOptions() on an options database that contains -ksp_view and then push another options database that does not contain -ksp_view and call KSPSetFromOptions() again it undoes the previous setting of that viewer.  So -ksp_view is not used.<br>
<br>
  I think this is the wrong model, it should not turn off the previously set view just because it is not being set in the new call, since it was previously set in the KSP. I fear some PETSc function will need another argument to properly handle this; like another flag to PetscOptionsGetViewer().<br>
<br>
  Note this is for much more than KSP.<br>
<br>
 Thoughts?<br></blockquote><div><br></div><div>I think it must get rid of it. Otherwise, it would stay forever since there would be no way to get rid of it.</div><div><br></div><div>  Matt </div></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><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.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><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.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>