AUTO,DT

[MF87]

Hello,

I have a problem with the understanding of the auto time stepping in my example. I use the standard auto time stepping with the commands

AUTO,TIME,IMIN,IMAX,MAXR
AUTO,DT,DTMIN,DTMAX

I have used FEAP for several years and I thought that I understood how the auto time stepping works. Now I observed some strange behaviour for the automatic time adaption in my attached example (see Ifile). In load step 23 (see Lfile and Ofile from lines 11154-11302) FEAP converges within 10 steps. Since I set IMIN to 15 and IMAX to 20 I thougth that FEAP will increase the time step since 10 is smaller than IMIN. But what I observe is that FEAP remains the time step constant (see Lfile and Ofile).

Do I miss anything or is there any additional requirement for the increase of the time step?

[Prof. R.L. Taylor]

There may be some conflicting aspects to the auto dt; however, I observed that the algorithm did attempt to increase the time step several times only to reduce again.  It would help to know which branch is causing the algorithm to behave as it is. I do see that the "rattle" flag is set which implies the solution has a on-off type iteration.  You can confirm by putting a write into the check area in pmacr2.f (in the [auto location) and see what is happening.  Better diagnostics are needed; and there is a comment that when this was added improvements were needed -- this was a long time ago and I do not recall who worked on it last.

There is no question that the problem is having difficulty getting throught this part of the solution.  Will it get easier later?

[MF87]

The example which I run is a crack propagation example of a circular plate with a hole.  Load step 23 is during the heavy force decrease which takes place as soon as the crack propagates. Later when the crack has run completely through the plate, the solution is obtained easier (see load steps 57-71). What exactly is this rattle check? How does it work? In other examples I sometimes get the error message "too many rattles" and the computation stops.
I assume that the rattel flag is "aratfl", right? Where do you see in the Ofile that the rattle flag is set? And can you specify where you want me to put the write statement in pmacr2.f (e.g. give me a line number).

Thanks a lot!

[Prof. R.L. Taylor]

Search the module pmacr2.f for the location where [auto] is defined; Look for the rattle area and see what is being set by printing to the output file or screen.

Line numbers are not reliable as coding changes from version to version (what version are you using?)

[MF87]

I use FEAP 8.4. I will do what you suggested, but I think it will not help me so much because I do not know about the algorithm which is behind this rattle check and I am not familiar with the used variables in pmacr2.f. I think it would be very dangerous to change something in the algorithm and therefore I will stick to the implemented version. Thank you for your effort!

[Prof. S. Govindjee]

The rattle flag goes back to 1992! when I was working on brittle damage in concrete.  The idea was pretty simple.  During implicit iterations one would often encounter situations where the residual was oscillating.  This was being caused by alternate damage propagation and healing while iterating.  The solution was a crude algorithm to detect the oscillations and then to force the time steps to be small until one got through the difficulty.

The algorithm is completely heuristic and I forget the details; I still have the development notes but will not have access to them until the end of December, as I am out of the office until them.  Notwithstanding, I believe that the code computes a measure to determine 'rattling' when non-convergence is detected.  This is the variable v4, exceeding 400 the code goes into rattle mode.  I believe it then forces time step reductions up to 5 times attempting to converge the time step.

All the code is contained under the [next] macro command.  Search for label 4 in program/pmacr2.f.

My recommendation is to if at all possible to use the newer AUTO,MATE time stepper, since it is physics based.

[MF87]

Thank you Prof. Govindjee. This already helped a lot. But for me, there is still one thing which confuses me: in pmacr2.f there is the following comment:

c           First Check for rattling residual before reducing time step;
c           if residual is rattling, then increase time step.

You wrote that this rattle check is in order to force the time steps to be small until one got through the difficulty, but what is written in the comment is the opposite, isn't it? I checked the code under the aforementioned comment, which is from my point of view the only important position in pmacr2.f where aratfl is used, namely when

if(aratfl) and
if(ior.lt.0)

are fulfilled, FEAP stops. But I do not see where aratfl forces FEAP either to remain with a small time step or to increase the time step. So I only see that FEAP terminates the computation at a certain point when the two aforementioned if-statements are fulfilled. Therefore I would like to deactivate somehow the Rattle Check. Can you recommend a way how to do it (without using AUTO,MATE)? AUTO,MATE does not work in my examples and therefore it would be nice to stay with the algorithm prescribed by AUTO,TIME,IMIN,IMAX,MAXR. Or is there maybe a possibility to combine AUTO,MATE with  AUTO,TIME,IMIN,IMAX,MAXR. In my example it is not sufficient to base the time increment only on the local material iteration. Based on the global iterations it works, so maybe a combination would be perfect.

Thanks a lot in advance!

[FEAP_Admin]

If you just want to shut off the rattle 'feature' then try the following:

Code: [Select]

              if(ior.lt.0) write(*,*) 'Rattle Check: ',v4
              write(iow,*) 'Rattle Check: ',v4
              v4 = 10.d0
Setting v4 to anything less than 400.d0 should disable the rattle feature.

[FEAP_Admin]

Btw, I just looked at the output file you posted.  While the rattle parameters are being printed they are all low and thus the rattle feature is not being activated.

[MF87]

Yes this is true. I also recognized this. I think the reason why the time increment is not increased after load step 23 is the following if-condition, which is not fulfilled in my case

Code: [Select]

if(iautl.lt.0) then
  call autdt(dt,dtnew, .true.)
  dt = dtnew
  iautl = 0
endif
I think that iautl is a counter which is set to 5 if the residual really diverges, see the following code:

Code: [Select]

         
if (autr(1).gt.1000.d0*autr0 .and. niter.ge.3) then
  call autdt(dt,dtnew, .false.)
  call autbac(dtnew)
  ct(1,l) = 1.0d0
  ct(3,l) = 1.0d0
  larept  = larept + 1
  iautl   = 5

end if
If in the next load steps, convergence is achieved, then iautl is reduced every load step by 1:

Code: [Select]

iautl = iautl - 1

[FEAP_Admin]

I was just looking at this too.  I think you are correct.  Try putting in a print in the block that sets iautl=5.  Also place a print where it checks if iautl is less than 0.

This check is essentially trying to say, if you recently had a very rough step, then wait until things settle down before increasing the time step size.

Everything in the auto time stepper is heuristic.  It could really use some improvement.

[MF87]

I checked it with the printing and it is exactly the case as you say. Now I understand the logic of the algorithm. I think in the Abaqus auto time stepping something similar is implemented.

In addition I checked the results for another example where I had the problem that FEAP stopped with the rattle statement 'BYE - too many rattles'. I set v4=10.d0 and now the computation is running through. So I think I will stay with this version where the rattle check is deactivated. Thanks!