# yade-users team mailing list archive

Last remark : You could decide to ignore velocities and save positions u(t-dt) somewhere to compute u(t+dt) as a function of u(t) and u(t-dt). It would be exactly the same scheme, but you would need post-processing to compute velocities at the end. No point doing that.
```
```
Note that critical time-step definition is also explained in my previous email.
```
Bruno

Bruno Chareyre a écrit :
```
```Jerome Duriez a écrit :
```
```And how are velocities (in both schemes) computed ?

```
If they are computed by the same mean, I can still not understand at all what is the difference between these two shemes, except the fact that "2nd order" sounds more serious than "1st order"...
```
```
```Héhé...

```
In first order scheme, you would use current velocity for p(t+dt) = p(t) + v(t)*dt, THEN you would compute v(t+dt)=..., in 2nd order, you use the updated (second) value instead. A while ago, Yade was using the 1st order scheme for rotations, and it was the reason why we needed so small time steps.
```
```
It seems many people have problems with this simple 2nd order explicit scheme. I send the equations in the attached file. I hope (should I?) it will stop endless discussions in my office about this. ;)
```
```
You will find the exact same scheme in any Cundall's paper, even if he doesn't explain it exactly the same way perhaps.
```
Bruno

```
```Jerome

Bruno Chareyre a écrit :
```
```The answer is (just for the record, I discussed that with Vincent) :

```
In a 2nd order finite difference scheme for Newtons law, positions and forces are defined at times t+Ndt, while velocities are defined at times t+(N+1/2)dt. If everything was defined at times Ndt, it would be a first order sheme.
```
v(t+0.5*dt) = v(t-0.5*dt) + a(t)*dt
p(t+dt) = p(t) + v(t+0.5*dt)*dt

Bruno

Vincent Richefeu a écrit :
```
(I re-send this mail because it didn't appear in yade-dev list... sorry if you receive it for a second time)
```

Hi everybody,

```
This morning I had a look at the file LeapFrogPositionIntegrator.cpp and I a little scarred of what I saw (I exaggerate of course).
```Can someone enlighten me on that point:
If I translate the c++ code into human readable operations, I've got:

v(t+dt) = v(t) + a(t)*dt
p(t+dt) = p(t) + v(t+dt)*dt + getMove

```
1. The first thing that seems odd to me is the use of v(t+dt) in the evaluation of p(t+dt). There's no great danger if the displacements are small and slow. However, it is know that even a quasistatic load may be accompanied by small localized dynamic crises. If there is indeed a problem here, no big deal because reducing the time step is enough to correct it. But it's a pity!
```
```
2. The second that I don't understand is the method getMove that seems to return a force (!) I know, I am probably wrong. Can anyone give me details on what this function returns ?
```
VR

_______________________________________________

```
```

```
```
_______________________________________________

```
```

------------------------------------------------------------------------

_______________________________________________
```
```

--

_______________
Chareyre Bruno
Maître de Conférences

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________

```