[petsc-users] Possibility of using out of date Jacobians with TS

Steve stevenbenbow at quintessa.org
Mon Aug 12 02:49:47 CDT 2019


Thanks Mark, if if I see similar performance I'll be very happy!

On 11/08/2019 15:17, Mark Lohry wrote:
> Anecdotal: I've been *shocked* at how long I can let the 
> -snes_lag_preconditioner go with -snes_mf_operator. I have it 
> configured to only recompute the preconditioner whenever it hits my 
> linear solver iteration limit, which pretty much never happens on 
> unsteady problems.
>
> On Fri, Aug 9, 2019 at 11:11 AM Steve via petsc-users 
> <petsc-users at mcs.anl.gov <mailto:petsc-users at mcs.anl.gov>> wrote:
>
>     Thank you Barry, that's very helpful.
>
>     I'll have a play with those various options and see how I get on.
>
>
>     On 09/08/2019 15:43, Smith, Barry F. wrote:
>     >     Steve,
>     >
>     >       There are two possibilities
>     >
>     > 1) completely under user control, when you are asked for a new
>     Jacobian you can evaluate the current conditions and decide
>     whether to generate a new one. For example get from SNES the
>     number of iterations it required and if that is starting to go up
>     then get a new one or check if the time-step is being cut because
>     the nonlinear solver is becoming "too hard" and generate a new one.
>     >
>     >     It is also possible to use -snes_mf_operator (or an inline
>     version) that uses matrix-free to apply the Jacobian and the
>     Jacobian you provide to compute the preconditioner. This allows
>     you to keep the current Jacobian/preconditioner even longer before
>     rebuilding. Here you can use the increase in the number of linear
>     iterations to decide when to change the Jacobian.
>     >
>     > 2) let PETSc decide when to rebuild the Jacobian. This is more
>     limited since it has no direct measure of how well the Jacobian is
>     doing. Some possibilities are
>     > -snes_lag_jacobian -snes_lag_jacobian_persists
>     -snes_lag_preconditioner -snes_lag_preconditioner_persists This
>     introduces yet another parameter under your control; you can lag
>     the generation of the new preconditioner even when you get a new
>     preconditioner (this makes sense only when you are not using
>     -snes_mf_operator),
>     >
>     >    So, at a high level, you have a great deal of freedom to
>     control when you recreate the Jacobian (and preconditioner), will
>     be problem dependent and the optimal value will depend on your
>     problem and specific integrator. Final note, when you rebuild may
>     also depend on how far you have integrated, when the nonlinear
>     effects are strong you probably want to rebuild often but when the
>     solution is close to linearly evolving less often.
>     >
>     >    If generating the Jacobian/preconditioner is expensive
>     relative to everything else a good combination is
>     -snes_mf_operator and a pretty lagged generation of new Jacobians.
>     >
>     >     Barry
>     >
>     >
>     >
>     >
>     >> On Aug 9, 2019, at 9:25 AM, Steve via petsc-users
>     <petsc-users at mcs.anl.gov <mailto:petsc-users at mcs.anl.gov>> wrote:
>     >>
>     >> Hi,
>     >>
>     >> I'm experimenting with the use of PETSc to replace a DAE solver
>     in an existing code that I use to solve stiff nonlinear problems. 
>     I expect to use TSBDF in the final instance, and so am currently
>     playing with it but applied to a simpler linear problem - just to
>     get some experience with the SNES/KSP/PC controls before diving in
>     to the hard problem.
>     >>
>     >> Below is some output from TSAdapt for the simple linear
>     problem, using TSBDF and PCLU, so that the linear algebra solve in
>     the newton loop is direct:
>     >>
>     >>      TSAdapt basic bdf 0:2 step   0 accepted t=0     +
>     1.000e-03 dt=2.000e-03  wlte=2.51e-07  wltea=   -1 wlter=   -1
>     >>          TSResidual...
>     >>          TSJacobian... calculate
>     >>          TSResidual...
>     >>      TSAdapt basic bdf 0:2 step   1 accepted t=0.001     +
>     2.000e-03 dt=4.000e-03  wlte=2.83e-07  wltea=   -1 wlter=   -1
>     >>          TSResidual...
>     >>          TSJacobian... calculate
>     >>          TSResidual...
>     >>      TSAdapt basic bdf 0:2 step   2 accepted t=0.003     +
>     4.000e-03 dt=8.000e-03  wlte=1.22e-07  wltea=   -1 wlter=   -1
>     >>          TSResidual...
>     >>          TSJacobian... calculate
>     >>          TSResidual...
>     >>
>     >> I have added the "TSResidual..." and "TSJacobian..." echoes so
>     that I can see when PETSc is requesting residuals and Jacobians to
>     be computed.  (This is the Jacobian routine specified via
>     TSSetIJacobian.)
>     >>
>     >> Regarding the above output, it appears that TS / SNES always
>     requests a new (I)Jacobian at each new timestep (after the first
>     residual is calculated).  I can see mathematically why this would
>     be the default choice, but had hoped that it might be possible for
>     out-of-date Jacobians to be used until they become inefficient. My
>     reason for wanting this is that the Jacobian calculations for the
>     intended application are particularly expensive, but for small
>     enough timesteps out-of-date Jacobians may be good enough, for a
>     few steps.
>     >>
>     >> Is there any way of specifying that out-of-date (I)Jacobians
>     can be tolerated (at the expense of increased Newton iterations,
>     or smaller timesteps)?  Alternatively would it make sense to
>     include callbacks to TS / SNES from the Jacobian evaluation
>     function to determine whether sufficiently few iterations have
>     been used that it might be safe to return the previously
>     calculated Jacobian (if I store a copy)?  If so, is there any
>     advice on how I should do this?
>     >>
>     >> NB. I see that there is an option for TSRHSJacobianSetReuse(),
>     but this only applies to the RHS component of the DAE (the G(t,u)
>     part, using the terminology from the manual), but I am not using
>     this as ultimately I expect to be solving strongly nonlinear
>     problems with no "slow" G(t,u) part.
>     >>
>     >> Any advice would be greatly appreciated.
>     >>
>     >>
>     -- 
>     Dr Steven J Benbow
>     Quintessa Ltd, First Floor, West Wing, Videcom House, Newtown
>     Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK
>     Tel: 01491 636246  DD: 01491 630051  Web: http://www.quintessa.org
>
>     Quintessa Limited is an employee-owned company registered in
>     England, Number 3716623.
>     Registered office: Quintessa Ltd, First Floor, West Wing, Videcom
>     House, Newtown Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK
>
>     If you have received this e-mail in error, please notify
>     privacy at quintessa.org <mailto:privacy at quintessa.org> and delete it
>     from your system
>
-- 
Dr Steven J Benbow
Quintessa Ltd, First Floor, West Wing, Videcom House, Newtown Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK
Tel: 01491 636246  DD: 01491 630051  Web: http://www.quintessa.org

Quintessa Limited is an employee-owned company registered in England, Number 3716623.
Registered office: Quintessa Ltd, First Floor, West Wing, Videcom House, Newtown Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK

If you have received this e-mail in error, please notify privacy at quintessa.org and delete it from your system

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20190812/a2af47be/attachment.html>


More information about the petsc-users mailing list