[petsc-users] SNES + linesearch hackery?

[Barry Smith]

> On Mar 24, 2016, at 2:41 PM, Andrew McRae <A.T.T.McRae at bath.ac.uk> wrote:
> 
> 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().
> 
> On 24 March 2016 at 17:39, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> > On Mar 24, 2016, at 10:18 AM, Andrew McRae <A.T.T.McRae at bath.ac.uk> wrote:
> >
> > I have a finite element discretisation of the following nonlinear equation:
> >
> > m*(phi_xx * phi_yy - phi_xy^2) = const,
> >
> > 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.
> 
>   Andrew
> 
>    So you are actually solving
> 
>   m(phi)*(phi_xx * phi_yy - phi_xy^2) - const = 0
> 
>   with finite elements for phi?
> 
> 
>     What are you providing for a Jacobian?
> 
> The Jacobian I give treats m as being independent of phi, so just whatever you get from linearising det(Hessian(phi)).

  Ahh, a Picard iteration :-)


>  
> 
> 
> >
> > I'm using PETSc's SNES  in Python via petsc4py, within the wider environment of the software Firedrake.
> >
> > 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.
> 
>     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?
> 
> 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.
> 
> Thanks,
> Andrew
>  
> 
>   Barry
> 
> >
> > 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.
> >
> > 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?
> >
> > Thanks,
> > Andrew
> 
>