[petsc-users] TSBEULER vs TSPSEUDO

[Francesc Levrero-Florencio]

Hi Jed,

Thanks for the answer.

We do have a monolithic arc-length implementation based on the TS/SNES logic, but we are also exploring having a custom SNESSHELL because the arc-length logic is substantially more complex than that of traditional load-controlled continuation methods. It works quite well, the only "issue" is its initiation; we are currently performing load-control (or displacement loading as you mentioned) in the first time increment. Besides load-control and arc-length control, what other continuation methods would you suggest exploring?

The test problem we are dealing with assumes plasticity but with small strains so we will not see any snap-throughs, snap-backs or similar. TSBEULER works quite well for this specific case and converges in a few time steps within around 5-10 SNES iterations per time step. What PETSc functions do you suggest exploring for implementing the TS time step extension control you mentioned?

Since you mentioned -ts_theta_initial_guess_extrapolate, is it worth using it in highly nonlinear mechanical problems (such as plasticity)? It sounds quite useful if it consistently reduces SNES iterations by one per time step, as each linear solve is quite expensive for large problems.

Regards,
Francesc.
________________________________
From: Jed Brown <jed at jedbrown.org>
Sent: 08 November 2022 17:09
To: Francesc Levrero-Florencio <francesc.levrero-florencio at ansys.com>; petsc-users at mcs.anl.gov <petsc-users at mcs.anl.gov>
Subject: Re: [petsc-users] TSBEULER vs TSPSEUDO

[External Sender]

First, I believe arc-length continuation is the right approach in this problem domain. I have a branch starting an implementation, but need to revisit it in light of some feedback (and time has been too short lately).

My group's nonlinear mechanics solver uses TSBEULER because it's convenient to parametrize loading on T=[0,1]. Unlike arc-length continuation, this can't handle snap-through effects. TSPSEUDO is the usual recommendation if you don't care about time accuracy, though you could register a custom controller for normal TS methods that implements any logic you'd like around automatically extending the time step without using a truncation error estimate.

Note that displacement loading (as usually implemented) is really bad (especially for models with plasticity) because increments that are large relative to the mesh size can invert elements or initiate plastic yielding when that would not happen if using smaller increments. Arc-length continuation also helps fix that problem.

Note that you can use extrapolation (-ts_theta_initial_guess_extrapolate), though I've found this to be somewhat brittle and only reduce SNES iteration count by about 1 per time step.

Francesc Levrero-Florencio <francesc.levrero-florencio at ansys.com> writes:

> Hi PETSc people,
>
> We are running highly nonlinear quasi-static (steady-state) mechanical finite element problems with PETSc, currently using TSBEULER and the basic time adapt scheme.
>
> What we do in order to tackle these nonlinear problems is to parametrize the applied loads with the time in the TS and apply them incrementally. While this usually works well, we have seen instances in which the adaptor would reject the time step according to the calculated truncation errors, even if the SNES converges in a small number of iterations. Another issue that we have recently observed is that in a sequence of converged time steps the adaptor decides to start cutting the time step to smaller and smaller values using the low clip default value of TSAdaptGetClip (again because the truncation errors are high enough). What can we do in order to avoid these issues? The first one is avoided by using TSAdaptSetAlwaysAccept, but the latter remains. We have tried setting the low clip value to its maximum accepted value of 1, but then the time increment does not increase even if the SNES always converges in 3 or 4 iterations. Maybe a solution is to increase the tolerances of the TSAdapt?
>
> Another potential solution we have recently tried in order to tackle these issues is using TSPSEUDO (and deparametrizing the applied loads), but generally find that it takes a much longer time to reach an acceptable solution compared with TSBEULER. We have mostly used the default KSPONLY option, but we'd like to explore TSPSEUDO with NEWTONLS. A first question would be: what happens if the SNES fails to converge, does the solution get updated somehow in the corresponding time step? We have performed a few tests with TSPSEUDO and NEWTONLS, setting the maximum number of SNES iterations to a relatively low number (e.g. 5), and then always setting the SNES as converged in the poststage function, and found that it performs reasonably well, at least better than with the default KSPONLY (does this make any sense?).
>
> Thanks a lot!
>
> Regards,
> Francesc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20221108/cb19b37e/attachment-0001.html>