Adaptive Time Increment Algorithm

[James Gorman]

deal.ii users,

I'm learning deal.ii with the goal of using it to non-linear solid mechanics problems. In many of these problems (such as Step-44), a time step is used to move a calculation from the initial condition to the final loaded state.

Step-44 uses a uniform time-step, but there are instances where an adaptive time step would be helpful. Using the initial parameter settings in 2-D, I found that a time-step of 0.7 was too large (the residual was on the order of 10^3) for the calculation to converge. 

I modified Step-44 to allow the time increment to increase the time increment when the number of Newton-Raphson iterations for two consecutive increments is small enough. I used global variables to make this happen.

I am, however, at a loss for how to efficiently make it so that Step-44 (or any other script) will automatically decrease a time-step. The only idea I had at the moment was to use a ``for'' loop and run a certain number of iterations, and each time the solution did not converge would be to multiply the time-step by some fraction. However, I am not sure this solution would work well with my previous solution 

Has anyone done this before, or have thoughts on how one might modify Step-44 to automatically increase and decrease based on the number of iterations required for Newton-Raphson convergence or divergence? Thank you for your help.

James

[Bruno Turcksin]

James,

On Tuesday, October 13, 2020 at 8:39:42 PM UTC-4 James Gorman wrote:

I am, however, at a loss for how to efficiently make it so that Step-44 (or any other script) will automatically decrease a time-step. The only idea I had at the moment was to use a ``for'' loop and run a certain number of iterations, and each time the solution did not converge would be to multiply the time-step by some fraction. However, I am not sure this solution would work well with my previous solution 

That's the right idea. You want to be careful that you don't end up reducing your time step too much though. Otherwise you could end up with a time step that is effectively zero.

Has anyone done this before, or have thoughts on how one might modify Step-44 to automatically increase and decrease based on the number of iterations required for Newton-Raphson convergence or divergence? Thank you for your help.

What you are trying to do  is similar to what embedded methods do but instead of using the error you are using the number of Newton iterations. Here is how embedded methods work in deal.II https://github.com/dealii/dealii/blob/master/include/deal.II/base/time_stepping.templates.h#L770-L857

Best,

Bruno

[Jean-Paul Pelteret]

Dear James,

I've got some snippets of code that I'll post below to show you how this can be done within the framework of step-44. The basic concept that I implemented is as follows:

- The nonlinear solver is called by some function who's job it is to solve for a single timestep. Collectively, they return a status that says what happened within the nonlinear solver. Essentially, the nonlinear solver declares that it took the optimal number of steps to converge (according to its settings), too few steps, too many steps (i.e. we stopped it at some maximum number of iterations), or it diverged completely. This is returned to the main function that performing the loop that steps through time.

- From within that loop, it now decides what to do. If the nonlinear solver converged, but took either the optimal number of steps (say, 3-6) or too few then it accepts the timestep (too few = still converged). If it took too many but still converged, then it will accept the step but the TS size should be adjusted. If the maximum number of iterations are hit without convergence or the solver diverged then we reject the timestep and will have to restart it completely (since this tutorial uses an implicit scheme, linearised about the current timestep, you basically have to reject anything that you've done in that time iterate and start the iterate again).

- It the nonlinear solver status is then converted to a message for the time stepper. If too few nonlinear iterations were performed, then it tells the time stepper that the timestep size was too small. If the optimal number of steps were taken then it says that the TS size is adequate. If too many steps were taken or the solver diverged then it informs the time stepper that the step size was too large; if no convergence was achieved during that step then it must be performed again after adjustment. (Without employing some sophisticated nonlinear solver, such as the arc length method, then hope is that reducing the timestep size will circumvent the conditions that lead to divergence.)

- The time stepper would then decide how it adjusts the time step size. A simple scheme would be to halve (or scale by some factor) the timestep size each time its declared to be too large, with some minimum value enforced. Similarly, if the time step size is too large then you could scale the time increment by a constant factor. This would be the most simple approach to try to implement first.

I think that those are the most important details. Attached is some code for you to peruse. I extracted it from a project of mine that used step-44 as its base, so if it looks like I cropped out anything important then just let me know and I'll try to fill in the gaps. Granted, it's not the easiest to understand but hopefully it, in conjunction with my summary, will give you some idea as to how you could move forward.

Best,

Jean-Paul

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/e0ec0522-510f-475c-bb9a-a615bd9b0800n%40googlegroups.com.

[James Gorman]

I apologize that it took so long to respond Jean-Paul, as some things came up that kept me away from working on this.

I was going through the code and attempted to integrate it within Step-44 as appropriate. I appreciate your willingness to share it with me, but I have some questions concerning error messages that were made when I tried to implement it.

The last portion of the code was commented as ``source''. Am I correct to assume you intended for this to be it's own header file to be included in the Step-44 introduction?

What was the type of ``first_cycle_refinement''? It appears to only show up once in the file you sent.

More errors than the two above occur in the code, but I want to try and work through them before asking for additional help...

Bruno, I do appreciate your suggestion, but since Jean-Paul was willing to share a portion of his code I'm going to try not to re-invent the wheel.

James

[Jean-Paul Pelteret]

Hi James,

> I was going through the code and attempted to integrate it within Step-44 as appropriate. I appreciate your willingness to share it with me, but I have some questions concerning error messages that were made when I tried to implement it.

You're welcome!

> The last portion of the code was commented as ``source''. Am I correct to assume you intended for this to be it's own header file to be included in the Step-44 introduction?

No, that was an indication that this part of the code should go into a source file (e.g. time_discretisation.cc) while the code snippet before it marked as "header" should go in the corresponding header file (e.g time_discretisation.h). Naturally, you can organise your code however you want.

> What was the type of ``first_cycle_refinement''? It appears to only show up once in the file you sent.

That's just a boolean to indicate if the code is at the very first timestep and is must perform several cycles of adaptive refinement (e.g. what step-5 or step-6 is doing) before accepting this refined state and proceeding to the remainder of the time dependent problem. Again, you could just ignore this if this is not what you're wanting to do. (And, naturally, you could structure your code completely differently to achieve the same effect.)

I hope that you've managed to make some more progress between the time that you raised these questions and now. If you have any more questions, feel free to ask.

Best,
Jean-Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/78b9ebeb-81ee-4029-91d8-079a729964cfn%40googlegroups.com.