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@.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. -- gmx-users mailing list gmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! * Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
