Re: [gmx-users] Re: pull=constraint gives zero forces
Hi Alex, 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. Best, Jaakko 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). I'll note that there are no forces when using constraints, so the fact that you get zero forces for a constrained run is not really surprising. I guess the thing is that it doesn't work to keep atoms in place for you, which we can help you with if you post more details. 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 -- gmx-users mailing listgmx-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
[gmx-users] Re: pull=constraint gives zero forces
Sorry - forgot to mention that before crashing, the run with all other constraints removed produces a single line of pullf output: 0. -812.401-4002.84482.04 1951.47 138.953 -1806.55 -601.0072644.79 447.018 1768.6 -214.64 -199.829-2746.97 1177.7 476.39 288.535 -559.274123.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 = 250 ; 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
Re: [gmx-users] Re: pull=constraint gives zero forces
Hi, Do you know there are issues with using pull=constraint on molecules that have constrained bonds? It's mentioned in the manual somewhere. Erik 9 okt 2012 kl. 11.39 skrev alex.bjorling: Sorry - forgot to mention that before crashing, the run with all other constraints removed produces a single line of pullf output: 0. -812.401-4002.84482.04 1951.47 138.953 -1806.55 -601.0072644.79 447.018 1768.6 -214.64 -199.829-2746.97 1177.7 476.39 288.535 -559.274123.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 = 250 ; 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
[gmx-users] Re: pull=constraint gives zero forces
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 alex.bjorling wrote I'm using the pull code to maintain the initial structure of a protein that otherwise deforms. Using pull=umbrella does what I expect it to, but pull=constraint produces zero forces. I'm using version 4.5.5 with the MARTINI force field. The pull=umbrella mdp contains the following, and gives the following pullf output: For such runs, the group COM:s stay within 0.1 nm of their initial positions, throughout a long trajectory. The pull=constraint mdp starts with and produces the pullf output For these runs, the group COM:s move around freely. I guess I'm doing something wrong but can't work out what. I've tried specifying k:s for the contraint runs, and tried removing all other constraints in the molecule. I've tried to comply with the manual's instructions but to no avail. Any ideas? Cheers, Alexander Björling, PhD candidate, University of Gothenburg, Sweden -- View this message in context: http://gromacs.5086.n6.nabble.com/pull-constraint-gives-zero-forces-tp5001538p5001793.html Sent from the GROMACS Users Forum mailing list archive at Nabble.com. -- gmx-users mailing listgmx-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
[gmx-users] Re: pull=constraint gives zero forces
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). I'll note that there are no forces when using constraints, so the fact that you get zero forces for a constrained run is not really surprising. I guess the thing is that it doesn't work to keep atoms in place for you, which we can help you with if you post more details. 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 -- gmx-users mailing listgmx-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
