[petsc-users] SNES + linesearch hackery?

[Andrew McRae]

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)).


>
>
> >
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160324/9654f153/attachment.html>