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-floren...@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.
