<div dir="ltr"><div>Hello,</div><div><br></div><div>I am one of the developers of a suite of advanced sampling techniques (SSAGES v0.8.2, <a href="https://github.com/MICCoM/SSAGES-public" target="_blank">https://github.com/MICCoM/SSAGES-public</a>) that ties in with several MD engines (including GROMACS). Ideally, our patching of GROMACS would be minimal, to keep the code bases relatively clean, so we are injecting some function definitions and calls into src/programs/mdrun/md.cpp (among others) by means of a patch (<a href="https://github.com/MICCoM/SSAGES-public/blob/master/hooks/gromacs/gmx_diff_2018.x.patch" target="_blank">https://github.com/MICCoM/SSAGES-public/blob/master/hooks/gromacs/gmx_diff_2018.x.patch</a>), with most of the calculations happening in our own code.</div><div><br></div><div>The bulk changes that our methods apply happens immediately after the do_force() call, via our PostIntegrationHook(). There are a couple methods that we have implemented that use techniques similar to Replica Exchange, in that they swap configurations. When using domain decomposition, these simulations will fail, due to wrapping around the periodic boundary conditions, causing a cg_move_error of &quot;Atom moved too far&quot;. The only thing that happens before this error is part of the molecule gets wrapped around the boundary, so there is a disconnect between the atom positions and in which domain decomposition cell it is.</div><div><br></div><div>I have tried changing the condition of </div><div>`if ( (bExchanged || bNeedRepartition) &amp;&amp; DOMAINDECOMP(cr) )` </div><div>to TRUE, just to see if that would fix the issue, as the system would be repartitioned into the proper domain decomposition cells (upon calling dd_partition_system). However, while this avoids the aforementioned crash, the atoms do not move at all (when visualized with VMD).</div><div><br></div><div>We were also thinking that triggering a neighbor list rebuild would fix this, but setting `nstlist = 1` had no effect on this error.</div><div><br></div><div>If there&#39;s any suggestions or ideas you might have about how we can go about alleviating this issue, we would greatly appreciate it. Below are instructions for building SSAGES and running a test case that exemplifies this issue.</div><div><br></div><div>Thanks in advance!</div><div>Michael Quevillon</div><div><br></div><div><br></div><div><br></div><div>Build instructions:</div><div><br></div><div>In order to compile SSAGES with GROMACS, run the following commands in the root folder (./), to build the executable at ./build/ssages:</div><div><br></div><div>mkdir build</div><div>cd build</div><div>cmake .. -DGROMACS=2018.1 -DGMX_BUILD_OWN_FFTW=yes</div><div>make</div><div><br></div><div>Within our code, there is an example that will fail relatively quickly. The example is alanine dipeptide in vacuum using the Swarm of Trajectories method. The files are located at ./Examples/User/Swarm/GMX_ADP. By default, the example is set up with 22 walkers, meaning you would need to run it with a multiple of 22 cores. The problem still exists with fewer walkers, and uses fewer resources. Please change 22 to 4 in Input_Generator.py, Template_Input.json, and copytpr.py. The source includes pre-compiled .tpr files, but can be regenerated with `gmx grompp -f nvt.mdp -c adp.gro -o adp.tpr`. Then, run the python scripts of Input_Generator.py and copytpr.py to set up the input files. Then, SSAGES can be run with `mpirun -np 8 ./ssages Swarm.json`, or any larger multiple of 4.</div></div>