<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thanks Mark, if if I see similar performance I'll be very happy!<br>
</p>
<div class="moz-cite-prefix">On 11/08/2019 15:17, Mark Lohry wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJ7aB-JmxXi2GCjRJA9mfixWs6iWsVJ+uzLvNt=RXEgt_oX=wA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">privacy@quintessa.org</a> and delete
it from your system<br>
<br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
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: <a class="moz-txt-link-freetext" href="http://www.quintessa.org">http://www.quintessa.org</a>
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 <a class="moz-txt-link-abbreviated" href="mailto:privacy@quintessa.org">privacy@quintessa.org</a> and delete it from your system</pre>
</body>
</html>