On 4/21/22 8:06 AM, Barry Smith wrote:
On Apr 21, 2022, at 8:52 AM, Phlipot, Greg <greg.phli...@jhuapl.edu> wrote:
I wish I could give you an definitive reason why, but I can't. Before
TS gets into this situtation where it needs to take a tiny time step,
TS takes time steps of ~1.0, and the shift in TSSetIJacobian is ~1.0.
Then it gets really close to the max time and the time step drops to
~1e-12 and the shift in TSSetIJacobian becomes ~1e12.
When this happens, my ILU-preconditioned gmres linear solve converges
in a single interation, and the backtracking line search in my newton
solver fails.
This is worth investigating. You can run with -ksp_monitor_true_residual
-ksp_converged_reason -snes_linesearch_monitor (preferably if you can rig the code to
"restart" near the end of the time interval so you don't have to spew this
stuff out for many time-steps).
A tiny time-step generally produces a well-conditioned linear system (and
nonlinear I would think also) so it may be peculiar to your ILU and tolerances
that are causing this situation.
I am bothered by the sudden absurdly small time step (not being an ODE
expert) and would hope that the adaptor could, for example, when it realizes a
tiny step would be next back up one step and do that one step again with a
modestly smaller time-step so that the last time-step is reasonably sized.
Barry is correct, BDFs are subject to instability if two consecutive
points in time are either too far or too close relative to the rest. I
think BDF2 is insensitive to decrease in time step, so try to limit the
BDF to order 2 if that is an option for you. Alternatively, try one-step
multistage methods (ARKIMEX, but use only the implicit part). While this
may not address directly the issue Greg is describing above, it's easy
to try out.
Emil
Barry
Thank you,Greg
On Thu, 2022-04-21 at 00:57 +0000, Zhang, Hong wrote:
APL external email warning: Verify sender hongzh...@anl.gov before
clicking links or attachments
On Apr 20, 2022, at 3:58 PM, Phlipot, Greg <greg.phli...@jhuapl.edu
wrote:
Hello,
When using TS with the option TS_EXACT_FINALTIME_MATCHSTEP to force
TS
to stop at the final time, I'm seeing the adaptive step controller
choose smaller time steps than the minimum time step that is set
with
TSAdaptGetStepLimits. For my problems, this leads to solutions that
won't converge due to numerical issues.
Can you please elaborate a bit on why the solution diverges when
using a small step size?
Thanks,
Hong (Mr.)
It seems like this might be due to the fact that TSAdaptChoose (
https://petsc.org/main/src/ts/adapt/interface/tsadapt.c.html#TSAdaptChoose
) uses a tolerance of 10*PETSC_MACHINE_EPSILON to compare whether
the
candidate time step is close to the final time. For me,
10*PETSC_MACHINE_EPSILON is much smaller than my smallest time step
so
the adaptation scheme occasionally chooses a time step that results
in
a time much closer to the max time than the minimum time step. The
subsequent time step is therefore forced to be smaller than the
minimum
time step.
Does anyone have an idea of a workaround (without changing the
source
code) where I would be able to modify this logic to use the minimum
time step instead of 10*PETSC_MACHINE_EPSILON? E.g. with Pre/Post
stage
callbacks and manually modifying the time step?
Thank you,
Greg
--
Emil M. Constantinescu, Ph.D.
Computational Mathematician
Argonne National Laboratory
Mathematics and Computer Science Division
Ph: 630-252-0926
http://www.mcs.anl.gov/~emconsta
