<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 1, 2015 at 7:42 AM, Stefano Zampini <span dir="ltr"><<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just noticed that the behaviour of a code like this<div><br></div><div>SNESSetType(snes,SNESASPIN)</div><div>SNESSetFromOptions(snes)<br><div><div><br></div><div>is not the same as </div><div><div><br></div><div>SNESSetType(snes,SNESNEWTONLS)</div><div>SNESSetFromOptions(snes)<br><div></div></div></div><div><br></div><div>when -snes_type newtonls is specified at command line. In both cases, the snes will be of type SNESNEWTONLS, but in the first case, the snes object will also have a nonlinear preconditioner embedded in, since SNESASPIN creates snes->pc, and there's no SNESDestroy_ASPIN.</div><div><br></div><div>What is the correct approach to fix this? Should the nonlinear preconditioner be destroyed by the SNESSetType interface or by the specific implementation of ASPIN?</div></div></div></div></blockquote><div><br></div><div>I wish Peter had not done it this way. His reason was that a special Jacobian action can be defined for</div><div>Newton -L NASM, but we should just do this with a flag rather than a new SNES type.</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 dir="ltr"><div><div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- <br></div><div>Stefano</div>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>