# Floaing rotation in Chrono

**URL:** <https://gpusph.discourse.group/t/floaing-rotation-in-chrono/173>\
**Category:** Uncategorized\
**Created:** [July 14, 2022, 10:38am UTC](https://gpusph.discourse.group/t/floaing-rotation-in-chrono/173 "2022-07-14T10:38:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![JoJo](https://avatars.discourse-cdn.com/v4/letter/j/ecd19e/32.png) [@JoJo](https://gpusph.discourse.group/u/JoJo)\
**Post date:** [July 14, 2022, 10:38am UTC](https://gpusph.discourse.group/t/floaing-rotation-in-chrono/173/1 "2022-07-14T10:38:07Z")

</div>

Hi, maybe you remember I fix the non-identical result when resuming a simulation with CHRONO before. [Code modification: resume with chrono body](https://gpusph.discourse.group/t/code-modification-resume-with-chrono-body/144)

I think these non-identical results are caused by acceleration data missing after resume. However, I have noticed that it is incorrect.

The real reason is that `SetRot()` executed after `SetWvel_par()`. Thus, to fix this problem, only need to ensure that `SetRot()` before all of the operators that change the angular data in CHRONO.

In function ‘restore\_moving\_body’ 5.0 master (shown as follow). though the acceleration data are stored in ‘next’, they are useless. What plays a role is that I adjusted the order between `SetRot()` and `SetWvel_par()`. Which is really a coincidence at that time, so I ignored it.

 ![image](https://global.discourse-cdn.com/free1/uploads/gpusph/original/1X/2bc04bf5c9858538789313a147667aaf9c19cda8.jpeg)

---

<div class="post-metadata">

**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\
**Post date:** [July 14, 2022, 12:46pm UTC](https://gpusph.discourse.group/t/floaing-rotation-in-chrono/173/2 "2022-07-14T12:46:29Z")

</div>

Dear @JoJo, thanks for your update with this information. A revised version of your previously proposed fix has been merged in the `next` branch already, so I don’t think we will change it again, but it’s interesting to know that the order in which things are restored is important. We should probably add a comment about this in the code.

Moreover, tracking the acceleration is also important to ensure that the dummy boundary conditions are applied correctly, so in general it’s a change that was needed anyway.