[gmx-users] Re: pull=constraint gives zero forces
alex.bjorling
alex.bjorling at gmail.com
Tue Oct 9 11:39:35 CEST 2012
Sorry - forgot to mention that before crashing, the run with all other
constraints removed produces a single line of pullf output:
0.0000 -812.401 -4002.84 482.04 1951.47 138.953 -1806.55
-601.007 2644.79 447.018 1768.6 -214.64 -199.829 -2746.97
1177.7 476.39 288.535 -559.274 123.08 114.493 851.86 550.558
As Thomas Schlesier mentions here,
http://gromacs.5086.n6.nabble.com/pull-constraint-gives-zero-forces-tp5001817.html,
the pullf output apparently contains the forces necessary to enforce the
constraints.
/ Alex
alex.bjorling wrote
> Thanks guys,
>
> Fixing the bug, recompiling and trying again results in a segfault
> like with version 4.0.7. I interpret this as GROMACS working fine, and
> suppose that there's something wrong with my input. Will continue this
> thread here and would really appreciate any ideas on how to proceed.
>
> Before the segfault, I get a bunch of LINCS warnings, all concerning
> atoms that have other constraints in the topology. Manually replacing
> these by stiff bonds in the itp gets rid of the LINCS warnings, but
> still produces an immediate segfault.
>
> The complete mdp follows. (Chris: previously posted via the web forum
> - it seems then you have to click the nabble link to see it).
>
> Cheers,
> Alex
>
> 50_constr3.mdp:
> ******************************************************************
> pull = constraint
> pull_geometry = position
> pull_dim = Y Y Y
> pull_start = yes
> pull_group0 = BB
> pull_nstxout = 1000
> pull_nstfout = 1000
> pull_ngroups = 7
> pull_constr_tol = 1e-6
>
> pull_group1 = group1
> pull_init1 = 0.0 0.0 0.0
> pull_rate1 = 0.0 0.0 0.0
>
> pull_group2 = group2
> pull_init2 = 0.0 0.0 0.0
> pull_rate2 = 0.0 0.0 0.0
>
> pull_group3 = group3
> pull_init3 = 0.0 0.0 0.0
> pull_rate3 = 0.0 0.0 0.0
>
> pull_group4 = group4
> pull_init4 = 0.0 0.0 0.0
> pull_rate4 = 0.0 0.0 0.0
>
> pull_group5 = group5
> pull_init5 = 0.0 0.0 0.0
> pull_rate5 = 0.0 0.0 0.0
>
> pull_group6 = group6
> pull_init6 = 0.0 0.0 0.0
> pull_rate6 = 0.0 0.0 0.0
>
> pull_group7 = group7
> pull_init7 = 0.0 0.0 0.0
> pull_rate7 = 0.0 0.0 0.0
>
> ;
> ; STANDARD MD INPUT OPTIONS FOR MARTINI 2.0 or 2.1
> ;
>
> ; TIMESTEP IN MARTINI
> ; Most simulations are numerically stable
> ; with dt=40 fs, some (especially rings) require 20-30 fs.
> ; Note that time steps of 40 fs and larger may create local heating or
> ; cooling in your system. Although the use of a heat bath will globally
> ; remove this effect, it is advised to check consistency of
> ; your results for somewhat smaller time steps in the range 20-30 fs.
> ; Time steps exceeding 40 fs should not be used; time steps smaller
> ; than 20 fs are also not required.
>
> ;define = -DPOSRES
> integrator = md
> tinit = 0.0
> dt = 0.02
> nsteps = 2500000 ; 50 ns
> nstcomm = 1
> comm-grps =
>
> nstxout = 0
> nstvout = 0
> nstfout = 0
> nstlog = 1000
> nstenergy = 100
> nstxtcout = 1000
> xtc_precision = 100
> xtc-grps =
> energygrps = Protein
>
> ; NEIGHBOURLIST and MARTINI
> ; Due to the use of shifted potentials, the noise generated
> ; from particles leaving/entering the neighbour list is not so large,
> ; even when large time steps are being used. In practice, once every
> ; ten steps works fine with a neighborlist cutoff that is equal to the
> ; non-bonded cutoff (1.2 nm). However, to improve energy conservation
> ; or to avoid local heating/cooling, you may increase the update frequency
> ; and/or enlarge the neighbourlist cut-off (to 1.4 nm). The latter option
> ; is computationally less expensive and leads to improved energy
> conservation
>
> nstlist = 10
> ns_type = grid
> pbc = xyz
> rlist = 1.4
>
> ; MARTINI and NONBONDED
> ; Standard cut-off schemes are used for the non-bonded interactions
> ; in the Martini model: LJ interactions are shifted to zero in the
> ; range 0.9-1.2 nm, and electrostatic interactions in the range 0.0-1.2
> nm.
> ; The treatment of the non-bonded cut-offs is considered to be part of
> ; the force field parameterization, so we recommend not to touch these
> ; values as they will alter the overall balance of the force field.
> ; In principle you can include long range electrostatics through the use
> ; of PME, which could be more realistic in certain applications
> ; Please realize that electrostatic interactions in the Martini model are
> ; not considered to be very accurate to begin with, especially as the
> ; screening in the system is set to be uniform across the system with
> ; a screening constant of 15. When using PME, please make sure your
> ; system properties are still reasonable.
>
> coulombtype = Shift
> rcoulomb_switch = 0.0
> rcoulomb = 1.2
> epsilon_r = 15
> vdw_type = Shift
> rvdw_switch = 0.9
> rvdw = 1.2
> DispCorr = No
>
> ; MARTINI and TEMPRATURE/PRESSURE
> ; normal temperature and pressure coupling schemes can be used.
> ; It is recommended to couple individual groups in your system separately.
> ; Good temperature control can be achieved with the Berendsen thermostat,
> ; using a coupling constant of the order of Ï„ = 1 ps. Even better
> ; temperature control can be achieved by reducing the temperature coupling
> ; constant to 0.1 ps, although with such tight coupling (Ï„ approaching
> ; the time step) one can no longer speak of a weak-coupling scheme.
> ; We therefore recommend a coupling time constant of at least 0.5 ps.
> ;
> ; Similarly, pressure can be controlled with the Berendsen barostat,
> ; with a coupling constant in the range 1-5 ps and typical compressibility
> ; in the order of 10-4 - 10-5 bar-1. Note that, in order to estimate
> ; compressibilities from CG simulations, you should use Parrinello-Rahman
> ; type coupling.
>
> tcoupl = Berendsen
> tc-grps = system
> tau_t = 1.0
> ref_t = 320
> Pcoupl = berendsen
> Pcoupltype = isotropic
> tau_p = 2.0
> compressibility = 3e-4
> ref_p = 1.0
>
> gen_vel = no
> gen_temp = 320
> gen_seed = 473529
>
> ; MARTINI and CONSTRAINTS
> ; for ring systems constraints are defined
> ; which are best handled using Lincs.
> ; Note, during energy minimization the constrainst should be
> ; replaced by stiff bonds.
>
> constraints = none
> constraint_algorithm = Lincs
> unconstrained_start = no
> lincs_order = 4
> lincs_warnangle = 30
>
> ******************************************************************
>
>
>
> 2012/10/9 Jaakko Uusitalo [via GROMACS]
> <
> ml-node+s5086n5001810h78 at .nabble
> >:
>>
>> constraint pulling has a bug in 4.5.5, see:
>> http://redmine.gromacs.org/issues/825. I'm guessing that's causing your
>> problems. Fixing it is very easy (see the link) or you can also use an
>> earlier version like 4.5.3 that works.
>>
>> On 9.10.12 2:26 , Christopher Neale wrote:
>>
>>> Please post your entire .mdp file and a snip of the output in your pullf
>>> and pullc files.
>>> (Your initial post on this topic was also missing these, although the
>>> text
>>> reads as if you intended to include them).
>>>
>>> Chris.
>>>
>>> -- original message --
>>>
>>> Following up on this post. I've tried the same runs using version 4.0.7,
>>> which gave immediate segmentation faults. Not sure if this is a clue or
>>> a
>>> trivial consequence of switching versions, but there it is.
>>>
>>> Any other ideas why the pullf output just contains zeros?
>>>
>>> Cheers,
>>> Alex
--
View this message in context: http://gromacs.5086.n6.nabble.com/pull-constraint-gives-zero-forces-tp5001538p5001819.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
More information about the gromacs.org_gmx-users
mailing list