# Moving atoms between repartition and force evaluation

**URL:** <https://ask.bioexcel.eu/t/moving-atoms-between-repartition-and-force-evaluation/308>\
**Category:** GROMACS\
**Created:** [March 6, 2017, 2:16pm UTC](https://ask.bioexcel.eu/t/moving-atoms-between-repartition-and-force-evaluation/308 "2017-03-06T14:16:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ibethune](https://avatars.discourse-cdn.com/v4/letter/i/58956e/32.png) [@ibethune](https://ask.bioexcel.eu/u/ibethune)\
**Post date:** [March 6, 2017, 2:16pm UTC](https://ask.bioexcel.eu/t/moving-atoms-between-repartition-and-force-evaluation/308/1 "2017-03-06T14:16:20Z")

</div>

Hi Gromacs developers,

I am hacking some experimental integrators into GROMACS (working with gromacs 5.0.2 for some historical reasons). In my scheme between the repartitioning at the start of the step ( dd\_partition\_system() ) and the later call to do\_force() I update the positions of some of the atoms. As a result, it seems that some of the contributions to the forces (the non-bonded part computed in do\_nb\_verlet() ) and also the part which arises from dd\_move\_f() are incorrect. I assume this is because some of the domain decomposition state is no longer correct given the new atom positions.

Is there some function I can call before do\_force() that will update the dd state (but not actually migrate any atoms since I was atoms to remain on the same process for the whole of the timestep?

Thanks

Iain

---

<div class="post-metadata">

**Author:** ![mabraham](https://dub1.discourse-cdn.com/flex013/user_avatar/ask.bioexcel.eu/mabraham/32/20_2.png) [@mabraham](https://ask.bioexcel.eu/u/mabraham)\
**Post date:** [March 7, 2017, 7:57am UTC](https://ask.bioexcel.eu/t/moving-atoms-between-repartition-and-force-evaluation/308/2 "2017-03-07T07:57:14Z")

</div>

Why not do your position update for home atoms after the normal position update, and thus be able to trust that the DD machinery will communicate the positions appropriately?

Other tips:

- partitioning and neighbour search happen on the same steps (with period nstlist), not necessarily every step
- it’s not sufficient to alter only one domain if any altered atom is present in a neighbour list on another domain
- you need to be sure that your updates will not violate the assumptions behind the neighbour list construction and thereby introduce drift unless you increase the buffering appropriately
- the gmx-developers mailing list is a better place for discussion of how best to hack on the code of GROMACS

---

<div class="post-metadata">

**Author:** ![ibethune](https://avatars.discourse-cdn.com/v4/letter/i/58956e/32.png) [@ibethune](https://ask.bioexcel.eu/u/ibethune)\
**Post date:** [March 7, 2017, 9:10am UTC](https://ask.bioexcel.eu/t/moving-atoms-between-repartition-and-force-evaluation/308/3 "2017-03-07T09:10:46Z")

</div>

Thanks Mark for the suggestions. The reason for doing it this way is that I need to have multiple force evalulations per step. I figured out the cause of my problem though, which was that the GMX\_FORCE\_NS flag was passed to do\_force in the second call, and if I removed it everything is working fine.

P.S. Thanks for the pointer to the gmx-developers list, I wasn’t aware of it.

- Iain