Re: [petsc-users] TSBEULER vs TSPSEUDO
Francesc Levrero-Florencio writes: > 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? Those are the main ones, and they're all simple expressions for the constraint condition that you have to handle for arc-length methods, thus suitable to make extensible. Wriggers' book has a nice discussion and table. I imagine we'll get some more experience with the tradeoffs after I add it to SNES. > 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? Check out src/ts/adapt/impls/ for the current implementations. > 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. I found sometimes it overshoots and thus causes problems, so effectiveness was problem-dependent. It's just a run-time flag so check it out. I'm curious if you have experience using BFGS with Jacobian scaling (either a V-cycle or a sparse direct solve) instead of Newton. You can try it using -snes_type qn -snes_qn_scale_type jacobian. This can greatly reduce the number of assemblies and preconditioner setups, and we find it also reduces total number of V-cycles so is effective even with our matrix-free p-MG (which are very fast and have much lower setup costs, https://arxiv.org/abs/2204.01722).
Re: [petsc-users] TSBEULER vs TSPSEUDO
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 Sent: 08 November 2022 17:09 To: Francesc Levrero-Florencio ; petsc-users@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 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.
Re: [petsc-users] TSBEULER vs TSPSEUDO
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 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.
[petsc-users] TSBEULER vs TSPSEUDO
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.
