Yes, &nbsp;this is a bug.<br>Please file a redmine issue.<br><br>Cheers,<br><br>Berk<br><br>----- Reply message -----<br>From: &quot;Shirts, Michael (mrs5pt)&quot; &lt;mrs5pt@eservices.virginia.edu&gt;<br>To: &quot;gmx-developers@gromacs.org&quot; &lt;gmx-developers@gromacs.org&gt;<br>Subject: [gmx-developers] Strange behavior with domain decomposition -- could this be handled more easily?<br>Date: Tue, Jun 19, 2012 02:27<br><br><br>Hi, all-<br><br>* The system: a grafted polymer system, 2D pbc in xy, with polymers attached<br>to one wall, and a second wall at z = 3x polymer length.<br><br>* The problem: When run with -nt &gt;=3, after a few hundred steps it quits<br>with errors of the<br><br>Step 210:<br>The charge group starting at atom 3067 moved than the distance allowed by<br>the domain decomposition in direction X<br>distance out of cell 1.755857<br>New coordinates: &nbsp; &nbsp;1.756 &nbsp; &nbsp;8.825 &nbsp; 33.301<br>Old cell boundaries in direction X: &nbsp; &nbsp;0.000 &nbsp; 28.000<br>New cell boundaries in direction X: &nbsp; &nbsp;0.000 &nbsp; 28.000<br><br>Fatal error:<br>A charge group moved too far between two domain decomposition steps<br>This usually means that your system is not well equilibrated<br>For more information and tips for troubleshooting, please check the GROMACS<br>website at http://www.gromacs.org/Documentation/Errors<br><br>* The diagnosis: It has to do with the automated domain decomposition<br><br>Automatically, it decided to start splitting the box in the z direction. &nbsp;It<br>starts with equal spacing in the z direction, but that means that there is a<br>lot of empty space at the top, so it starts to dynamically move the<br>divisions between boxes down. &nbsp;Eventually, as the boxes are moving down,<br>they intersect the polymer. &nbsp;Since it&#39;s adjusting so quickly to all the<br>empty space, the box boundaries are moving fast. &nbsp;It interprets this as the<br>polymer moving, not the boundary, and assumes the simulation is blowing up.<br><br>* The solution: Manually set the domain decomposition with the<br>flag -dd to mdrun. We avoid decomposition in the z direction, so<br>for 8 cores, set something like -dd 4 2 1.<br><br>* The question: Is something that can be automatically detected in the code?<br>It was not at all obvious what was going on at first, and most users would<br>have to give up -- I needed to debug for a while to identify this. &nbsp;Perhaps<br>the scaling be adjusted so that the box moved a maximum absolute distance as<br>well as a maximum percent, so that drawing of the box boundaries is never<br>larger than the &quot;moved too much&quot; distance?<br><br>I&#39;m happy to file a redmine with sample files if we can indeed consider this<br>a bug. &nbsp;I would consider a crash for a &quot;not wrong&quot; setup without proper<br>description of why it happened and how to avoid it to be a bug.<br><br>Best,<br>~~~~~~~~~~~~<br>Michael Shirts<br>Assistant Professor<br>Department of Chemical Engineering<br>University of Virginia<br>michael.shirts@virginia.edu<br>(434)-243-1821<br><br>-- <br>gmx-developers mailing list<br>gmx-developers@gromacs.org<br>http://lists.gromacs.org/mailman/listinfo/gmx-developers<br>Please don&#39;t post (un)subscribe requests to the list. Use the <br>www interface or send it to gmx-developers-request@gromacs.org.<br>