[gmx-users] pull-code constant-force direction gives unexpected error about distance larger than box size

[Christopher Neale]

Commenting out the gmx_fatal() call in src/mdlib/pull.c, line: 331 and recompiling grompp and mdrun
allows the run to proceed. Everything is stable for 250 ps. I will report if it fails.

I have posted a redmine at: http://redmine.gromacs.org/issues/1352

Thank you,
Chris.

-- original message --

I am trying to use the pull code to add a constant force in a particular direction.
I am getting an error that the initial distance is greater than 1/2 the box size.
(error in 4.5.5, 4.6.1, 4.6.3)

I must not understand how to use this. I checked the online .mdp options:
http://manual.gromacs.org/online/mdp_opt.html#pull

which read as if there is no concept of "distance" in this case, just an applied force along the specified vector.

One reason I know that I clearly don't understand is that if my interpretation of "constant-force, direction"
was correct, I can't see the need for pull_geometry=direction-periodic.

My .mdp options are:
pull                    = constant-force
pull_geometry           = direction
pull_dim                = Y Y Y
pull_nstxout            = 500
pull_nstfout            = 500
pull_ngroups            = 1
pull_group1             = r_1_&_CA
pull_pbcatom1           = 0
pull_k1                 = 30
pull_vec1               = -0.848 -0.179 0.497


And when I run:
grompp -p ../this.top -c ../start.gro -n ../index.ndx -f this.mdp

The error message is:
Pull group 1 'r_1_&_CA' has 1 atoms
Number of degrees of freedom in T-Coupling group System is 113574.00

WARNING 1 [file this.mdp]:
  You are using an absolute reference for pulling, but the rest of the
  system does not have an absolute reference. This will lead to artifacts.

Largest charge group radii for Van der Waals: 0.040, 0.040 nm
Largest charge group radii for Coulomb:       0.079, 0.079 nm
Calculating fourier grid dimensions for X Y Z
Using a fourier grid of 64x64x96, spacing 0.117 0.117 0.110
Pull group  natoms  pbc atom  distance at start     reference at t=0
       0         0         0
       1         1         0
-------------------------------------------------------
Program grompp, VERSION 4.6.3
Source code file: /project/p/pomes/cneale/GPC/exe/intel/gromacs-4.6.3/source/src/mdlib/pull.c, line: 331

Fatal error:
Distance of pull group 1 (4.706043 nm) is larger than 0.49 times the box size (3.738000)
For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
-------------------------------------------------------


###

Looking at the positions, vectors, and derived "distances":

initial position: 5.466   3.477   2.453
pull_vec1: -0.848 -0.179 0.497
box:   7.47600   7.47600  10.55300
shortest dist: 2.858 3.656 1.956 = 5.036 nm
length from initial position to (0,0,0): 2.01 3.477 2.453 = 4.706

But why does it matter what the distance from (0,0,0) to the initial position is?

Moreover, adding pull_start = yes does not change the error , nor does setting pull_init1 = 5.466   3.477   2.453 
(I didn't expect pull_init1 to have any effect, but I tried it just in case).

Finally, If I do use direction-periodic, I don't get an error with grompp, but I get the following output,
which is hard for me to align with my current understanding of what the pull code should be doing:

Pull group  natoms  pbc atom  distance at start     reference at t=0
       0         0         0
       1         1         0   2.301                 0.000

(why is there a "distance at start" and why is the reference at t=0 affected if I set:
pull_init1 = 5.466   3.477   2.453

Pull group  natoms  pbc atom  distance at start     reference at t=0
       0         0         0
       1         1         0   2.301                 5.466

when pull_init1 is supposed to be ignored for constant-force pulling?

This may be related to: http://gromacs.5086.x6.nabble.com/constant-force-pulling-td5010180.html

Perhaps the problem is simply that this error should not be thrown in this case? Hard to believe nobody has caught that over the years so it must be something else.

Thank you,
Chris.