[petsc-users] SNES + linesearch hackery?

[Andrew McRae]

On 24 March 2016 at 20:11, Matthew Knepley <knepley at gmail.com> wrote:

> On Thu, Mar 24, 2016 at 3:06 PM, Andrew McRae <A.T.T.McRae at bath.ac.uk>
> wrote:
>
>> On 24 March 2016 at 19:49, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>>
>>> > 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 :-)
>>>
>>
>> Not quite, I think.
>>
>> Ah, that should have read "so just m*(whatever you get from
>> linearising...)", and I was updating m between nonlinear iterations :)
>>
>
> 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
> used that for the step, then updated the frozen part. That is what lots of
> people call a Picard step.
>
>   Matt
>

I see, thanks.


>
>
>>
>>>
>>> >
>>> >
>>> >
>>> > >
>>> > > 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
>>> >
>>> >
>>>
>>>
>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160324/e0d6e230/attachment.html>