<div dir="ltr">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. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 9, 2019 at 11:11 AM Steve via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you Barry, that's very helpful.<br>
<br>
I'll have a play with those various options and see how I get on.<br>
<br>
<br>
On 09/08/2019 15:43, Smith, Barry F. wrote:<br>
> Steve,<br>
><br>
> There are two possibilities<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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<br>
> -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),<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Barry<br>
><br>
><br>
><br>
><br>
>> On Aug 9, 2019, at 9:25 AM, Steve via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> 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.<br>
>><br>
>> 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:<br>
>><br>
>> 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<br>
>> TSResidual...<br>
>> TSJacobian... calculate<br>
>> TSResidual...<br>
>> 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<br>
>> TSResidual...<br>
>> TSJacobian... calculate<br>
>> TSResidual...<br>
>> 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<br>
>> TSResidual...<br>
>> TSJacobian... calculate<br>
>> TSResidual...<br>
>><br>
>> 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.)<br>
>><br>
>> 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.<br>
>><br>
>> 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?<br>
>><br>
>> 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.<br>
>><br>
>> Any advice would be greatly appreciated.<br>
>><br>
>><br>
-- <br>
Dr Steven J Benbow<br>
Quintessa Ltd, First Floor, West Wing, Videcom House, Newtown Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK<br>
Tel: 01491 636246 DD: 01491 630051 Web: <a href="http://www.quintessa.org" rel="noreferrer" target="_blank">http://www.quintessa.org</a><br>
<br>
Quintessa Limited is an employee-owned company registered in England, Number 3716623.<br>
Registered office: Quintessa Ltd, First Floor, West Wing, Videcom House, Newtown Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK<br>
<br>
If you have received this e-mail in error, please notify <a href="mailto:privacy@quintessa.org" target="_blank">privacy@quintessa.org</a> and delete it from your system<br>
<br>
</blockquote></div>