<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 24, 2016 at 3:06 PM, Andrew McRae <span dir="ltr"><<a href="mailto:A.T.T.McRae@bath.ac.uk" target="_blank">A.T.T.McRae@bath.ac.uk</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"><div class="gmail_extra"><div class="gmail_quote">On 24 March 2016 at 19:49, Barry Smith <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><br>
> On Mar 24, 2016, at 2:41 PM, Andrew McRae <<a href="mailto:A.T.T.McRae@bath.ac.uk" target="_blank">A.T.T.McRae@bath.ac.uk</a>> wrote:<br>
><br>
> Apologies, in the end it seems this was more of a Firedrake question: with the help of Lawrence Mitchell, I now believe I should simply intercept SNESFormFunction().<br>
><br>
> On 24 March 2016 at 17:39, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Mar 24, 2016, at 10:18 AM, Andrew McRae <<a href="mailto:A.T.T.McRae@bath.ac.uk" target="_blank">A.T.T.McRae@bath.ac.uk</a>> wrote:<br>
> ><br>
> > I have a finite element discretisation of the following nonlinear equation:<br>
> ><br>
> > m*(phi_xx * phi_yy - phi_xy^2) = const,<br>
> ><br>
> > solving for phi. Unfortunately, the function m depends on phi in a complicated way -- let's assume I need to call my own function to handle this.<br>
><br>
> Andrew<br>
><br>
> So you are actually solving<br>
><br>
> m(phi)*(phi_xx * phi_yy - phi_xy^2) - const = 0<br>
><br>
> with finite elements for phi?<br>
><br>
><br>
> What are you providing for a Jacobian?<br>
><br>
> The Jacobian I give treats m as being independent of phi, so just whatever you get from linearising det(Hessian(phi)).<br>
<br>
</span> Ahh, a Picard iteration :-)<br></blockquote><div><br></div><div>Not quite, I think.<br><br></div><div>Ah, that should have read "so just m*(whatever you get from linearising...)", and I was updating m between nonlinear iterations :)</div></div></div></div></blockquote><div><br></div><div>I think Barry is right. You can look at it this way. You froze a portion of your system, took the Jacobian of the rest, and</div><div>used that for the step, then updated the frozen part. That is what lots of people call a Picard step.</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 class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
<br>
><br>
><br>
><br>
> ><br>
> > I'm using PETSc's SNES in Python via petsc4py, within the wider environment of the software Firedrake.<br>
> ><br>
> > Currently I'm hacking in the m update (and various output diagnostics) by writing a Python function "fakemonitor" and calling snes.setMonitor(fakemonitor). This allows me to update m each nonlinear iteration.<br>
><br>
> Hmm, I don't understand this. It sounds like you are passing (phi_xx * phi_yy - phi_xy^2) or something to SNES as the SNESFormFunction()? Why is this? Why not pass the entire function to SNES?<br>
><br>
> I was passing in m(phi^n)(phi_xx * phi_yy - phi_xy^2) - const, i.e., m was effectively frozen from the last nonlinear iteration. As stated above, I think it's as simple as arranging for m to be updated whenever SNESFormFunction() is called, which involves hacking Firedrake code but not PETSc code.<br>
><br>
> Thanks,<br>
> Andrew<br>
><br>
><br>
> Barry<br>
><br>
> ><br>
> > While this is better than nothing, there's still some problems: if I use e.g. snes_linesearch_type: "l2", the fnorms for lambda = 1.0, 0.5 and 0.0 are calculated without updating m, and so the step length taken is (seemingly) far from optimal. I tried adding a damping parameter, but all this does is change the lambdas used to generate the quadratic fit; it doesn't actually make the step length smaller.<br>
> ><br>
> > Is there some cleaner way to do what I want, perhaps by intercepting the fnorm calculation to update m, rather than abusing a custom monitor routine?<br>
> ><br>
> > Thanks,<br>
> > Andrew<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></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>