<div dir="ltr">Hi,<div><br></div><div>Yes, that's a problem long fixed, and several orders of magnitude larger.</div><div><br></div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 15, 2015 at 6:16 PM Bernhard <<a href="mailto:b.reuter@uni-kassel.de">b.reuter@uni-kassel.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I remember some research article <a href="http://dx.doi.org/10.1063/1.2431176" rel="noreferrer" target="_blank">http://dx.doi.org/10.1063/1.2431176</a> (or<br>
<a href="https://www.deshawresearch.com/publications/A%20common,%20avoidable%20source%20of%20error%20in%20molecular%20dynamics%20integrators.pdf" rel="noreferrer" target="_blank">https://www.deshawresearch.com/publications/A%20common,%20avoidable%20source%20of%20error%20in%20molecular%20dynamics%20integrators.pdf</a>)<br>
from 2006 which showed a comparable linear energy drift for single<br>
precision GROMACS 3.3.1 due to not optimal calculation of the velocity<br>
of constrained particels.<br>
But this issue should be solved in version 4.6.7?<br>
<br>
Best,<br>
Bernhard<br>
<br>
Am 15/07/15 um 18:04 schrieb Bernhard:<br>
> Indeed seems so... unfortunately I have no clue about the cause.<br>
> Maybe the head of the .log file is of some use?<br>
><br>
> Log file opened on Wed Jul 1 17:33:48 2015<br>
> Host: theo2-pc20 pid: 15411 nodeid: 0 nnodes: 1<br>
> Gromacs version: VERSION 4.6.7<br>
> Precision: single<br>
> Memory model: 64 bit<br>
> MPI library: thread_mpi<br>
> OpenMP support: enabled<br>
> GPU support: disabled<br>
> invsqrt routine: gmx_software_invsqrt(x)<br>
> CPU acceleration: AVX_256<br>
> FFT library: fftw-3.3.2-sse2<br>
> Large file support: enabled<br>
> RDTSCP usage: enabled<br>
> Built on: Di 16. Jun 15:38:40 CEST 2015<br>
> Built by: berni@theo2-pc20 [CMAKE]<br>
> Build OS/arch: Linux 3.13.0-43-generic x86_64<br>
> Build CPU vendor: GenuineIntel<br>
> Build CPU brand: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz<br>
> Build CPU family: 6 Model: 62 Stepping: 4<br>
> Build CPU features: aes apic avx clfsh cmov cx8 cx16 f16c htt lahf_lm<br>
> mmx msr nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdrnd rdtscp<br>
> sse2 sse3 sse4.1 sse4.2 ssse3 tdt x2apic<br>
> C compiler: /usr/bin/cc GNU cc (Ubuntu 4.8.2-19ubuntu1) 4.8.2<br>
> C compiler flags: -mavx -Wextra -Wno-missing-field-initializers<br>
> -Wno-sign-compare -Wall -Wno-unused -Wunused-value<br>
> -Wno-unused-parameter -Wno-array-bounds -Wno-maybe-uninitialized<br>
> -Wno-strict-overflow -fomit-frame-pointer -funroll-all-loops<br>
> -fexcess-precision=fast -O3 -DNDEBUG<br>
><br>
><br>
> :-) G R O M A C S (-:<br>
><br>
> GROwing Monsters And Cloning Shrimps<br>
><br>
> :-) VERSION 4.6.7 (-:<br>
><br>
> Contributions from Mark Abraham, Emile Apol, Rossen Apostolov,<br>
> Herman J.C. Berendsen, Aldert van Buuren, Pär Bjelkmar,<br>
> Rudi van Drunen, Anton Feenstra, Gerrit Groenhof, Christoph<br>
> Junghans,<br>
> Peter Kasson, Carsten Kutzner, Per Larsson, Pieter Meulenhoff,<br>
> Teemu Murtola, Szilard Pall, Sander Pronk, Roland Schulz,<br>
> Michael Shirts, Alfons Sijbers, Peter Tieleman,<br>
><br>
> Berk Hess, David van der Spoel, and Erik Lindahl.<br>
><br>
> Copyright (c) 1991-2000, University of Groningen, The Netherlands.<br>
> Copyright (c) 2001-2012,2013, The GROMACS development team at<br>
> Uppsala University & The Royal Institute of Technology, Sweden.<br>
> check out <a href="http://www.gromacs.org" rel="noreferrer" target="_blank">http://www.gromacs.org</a> for more information.<br>
><br>
> This program is free software; you can redistribute it and/or<br>
> modify it under the terms of the GNU Lesser General Public License<br>
> as published by the Free Software Foundation; either version 2.1<br>
> of the License, or (at your option) any later version.<br>
><br>
> :-) mdrun (-:<br>
><br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> B. Hess and C. Kutzner and D. van der Spoel and E. Lindahl<br>
> GROMACS 4: Algorithms for highly efficient, load-balanced, and scalable<br>
> molecular simulation<br>
> J. Chem. Theory Comput. 4 (2008) pp. 435-447<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> D. van der Spoel, E. Lindahl, B. Hess, G. Groenhof, A. E. Mark and H.<br>
> J. C.<br>
> Berendsen<br>
> GROMACS: Fast, Flexible and Free<br>
> J. Comp. Chem. 26 (2005) pp. 1701-1719<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> E. Lindahl and B. Hess and D. van der Spoel<br>
> GROMACS 3.0: A package for molecular simulation and trajectory analysis<br>
> J. Mol. Mod. 7 (2001) pp. 306-317<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> H. J. C. Berendsen, D. van der Spoel and R. van Drunen<br>
> GROMACS: A message-passing parallel molecular dynamics implementation<br>
> Comp. Phys. Comm. 91 (1995) pp. 43-56<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
> Input Parameters:<br>
> integrator = md<br>
> nsteps = 10000000<br>
> init-step = 0<br>
> cutoff-scheme = Verlet<br>
> ns_type = Grid<br>
> nstlist = 10<br>
> ndelta = 2<br>
> nstcomm = 100<br>
> comm-mode = Linear<br>
> nstlog = 5000<br>
> nstxout = 5000<br>
> nstvout = 5000<br>
> nstfout = 0<br>
> nstcalcenergy = 100<br>
> nstenergy = 1000<br>
> nstxtcout = 1000<br>
> init-t = 0<br>
> delta-t = 0.001<br>
> xtcprec = 1000<br>
> fourierspacing = 0.12<br>
> nkx = 60<br>
> nky = 60<br>
> nkz = 60<br>
> pme-order = 4<br>
> ewald-rtol = 1e-05<br>
> ewald-geometry = 0<br>
> epsilon-surface = 0<br>
> optimize-fft = FALSE<br>
> ePBC = xyz<br>
> bPeriodicMols = FALSE<br>
> bContinuation = TRUE<br>
> bShakeSOR = FALSE<br>
> etc = Nose-Hoover<br>
> bPrintNHChains = FALSE<br>
> nsttcouple = 10<br>
> epc = No<br>
> epctype = Isotropic<br>
> nstpcouple = -1<br>
> tau-p = 1<br>
> ref-p (3x3):<br>
> ref-p[ 0]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> ref-p[ 1]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> ref-p[ 2]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> compress (3x3):<br>
> compress[ 0]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> compress[ 1]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> compress[ 2]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> refcoord-scaling = No<br>
> posres-com (3):<br>
> posres-com[0]= 0.00000e+00<br>
> posres-com[1]= 0.00000e+00<br>
> posres-com[2]= 0.00000e+00<br>
> posres-comB (3):<br>
> posres-comB[0]= 0.00000e+00<br>
> posres-comB[1]= 0.00000e+00<br>
> posres-comB[2]= 0.00000e+00<br>
> verlet-buffer-drift = 0.005<br>
> rlist = 1<br>
> rlistlong = 1<br>
> nstcalclr = 10<br>
> rtpi = 0.05<br>
> coulombtype = PME<br>
> coulomb-modifier = Potential-shift<br>
> rcoulomb-switch = 0<br>
> rcoulomb = 1<br>
> vdwtype = Cut-off<br>
> vdw-modifier = Potential-shift<br>
> rvdw-switch = 0<br>
> rvdw = 1<br>
> epsilon-r = 1<br>
> epsilon-rf = inf<br>
> tabext = 1<br>
> implicit-solvent = No<br>
> gb-algorithm = Still<br>
> gb-epsilon-solvent = 80<br>
> nstgbradii = 1<br>
> rgbradii = 1<br>
> gb-saltconc = 0<br>
> gb-obc-alpha = 1<br>
> gb-obc-beta = 0.8<br>
> gb-obc-gamma = 4.85<br>
> gb-dielectric-offset = 0.009<br>
> sa-algorithm = Ace-approximation<br>
> sa-surface-tension = 2.05016<br>
> DispCorr = EnerPres<br>
> bSimTemp = FALSE<br>
> free-energy = no<br>
> nwall = 0<br>
> wall-type = 9-3<br>
> wall-atomtype[0] = -1<br>
> wall-atomtype[1] = -1<br>
> wall-density[0] = 0<br>
> wall-density[1] = 0<br>
> wall-ewald-zfac = 3<br>
> pull = no<br>
> rotation = FALSE<br>
> disre = No<br>
> disre-weighting = Conservative<br>
> disre-mixed = FALSE<br>
> dr-fc = 1000<br>
> dr-tau = 0<br>
> nstdisreout = 100<br>
> orires-fc = 0<br>
> orires-tau = 0<br>
> nstorireout = 100<br>
> dihre-fc = 0<br>
> em-stepsize = 0.01<br>
> em-tol = 10<br>
> niter = 20<br>
> fc-stepsize = 0<br>
> nstcgsteep = 1000<br>
> nbfgscorr = 10<br>
> ConstAlg = Lincs<br>
> shake-tol = 0.0001<br>
> lincs-order = 4<br>
> lincs-warnangle = 30<br>
> lincs-iter = 1<br>
> bd-fric = 0<br>
> ld-seed = 1993<br>
> cos-accel = 0<br>
> deform (3x3):<br>
> deform[ 0]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> deform[ 1]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> deform[ 2]={ 0.00000e+00, 0.00000e+00, 0.00000e+00}<br>
> adress = FALSE<br>
> userint1 = 0<br>
> userint2 = 0<br>
> userint3 = 0<br>
> userint4 = 0<br>
> userreal1 = 0<br>
> userreal2 = 0<br>
> userreal3 = 0<br>
> userreal4 = 0<br>
> grpopts:<br>
> nrdf: 1501.9 44334.1<br>
> ref-t: 300 300<br>
> tau-t: 2.5 2.5<br>
> anneal: No No<br>
> ann-npoints: 0 0<br>
> acc: 0 0 0<br>
> nfreeze: N N N<br>
> energygrp-flags[ 0]: 0<br>
> efield-x:<br>
> n = 0<br>
> efield-xt:<br>
> n = 0<br>
> efield-y:<br>
> n = 0<br>
> efield-yt:<br>
> n = 0<br>
> efield-z:<br>
> n = 0<br>
> efield-zt:<br>
> n = 0<br>
> bQMMM = FALSE<br>
> QMconstraints = 0<br>
> QMMMscheme = 0<br>
> scalefactor = 1<br>
> qm-opts:<br>
> ngQM = 0<br>
> Using 1 MPI thread<br>
> Using 12 OpenMP threads<br>
><br>
> Detecting CPU-specific acceleration.<br>
> Present hardware specification:<br>
> Vendor: GenuineIntel<br>
> Brand: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz<br>
> Family: 6 Model: 62 Stepping: 4<br>
> Features: aes apic avx clfsh cmov cx8 cx16 f16c htt lahf_lm mmx msr<br>
> nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdrnd rdtscp sse2<br>
> sse3 sse4.1 sse4.2 ssse3 tdt x2apic<br>
> Acceleration most likely to fit this hardware: AVX_256<br>
> Acceleration selected at GROMACS compile time: AVX_256<br>
><br>
> Will do PME sum in reciprocal space.<br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> U. Essmann, L. Perera, M. L. Berkowitz, T. Darden, H. Lee and L. G.<br>
> Pedersen<br>
> A smooth particle mesh Ewald method<br>
> J. Chem. Phys. 103 (1995) pp. 8577-8592<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
> Will do ordinary reciprocal space Ewald sum.<br>
> Using a Gaussian width (1/beta) of 0.320163 nm for Ewald<br>
> Cut-off's: NS: 1 Coulomb: 1 LJ: 1<br>
> Long Range LJ corr.: <C6> 2.8855e-04<br>
> System total charge: 0.000<br>
> Generated table with 1000 data points for Ewald.<br>
> Tabscale = 500 points/nm<br>
> Generated table with 1000 data points for LJ6.<br>
> Tabscale = 500 points/nm<br>
> Generated table with 1000 data points for LJ12.<br>
> Tabscale = 500 points/nm<br>
> Generated table with 1000 data points for 1-4 COUL.<br>
> Tabscale = 500 points/nm<br>
> Generated table with 1000 data points for 1-4 LJ6.<br>
> Tabscale = 500 points/nm<br>
> Generated table with 1000 data points for 1-4 LJ12.<br>
> Tabscale = 500 points/nm<br>
><br>
> Using AVX-256 4x4 non-bonded kernels<br>
><br>
> Using Lorentz-Berthelot Lennard-Jones combination rule<br>
><br>
> Potential shift: LJ r^-12: 1.000 r^-6 1.000, Ewald 1.000e-05<br>
> Initialized non-bonded Ewald correction tables, spacing: 6.60e-04<br>
> size: 3033<br>
><br>
> Pinning threads with an auto-selected logical core stride of 1<br>
><br>
> Initializing LINear Constraint Solver<br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> B. Hess and H. Bekker and H. J. C. Berendsen and J. G. E. M. Fraaije<br>
> LINCS: A Linear Constraint Solver for molecular simulations<br>
> J. Comp. Chem. 18 (1997) pp. 1463-1472<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
> The number of constraints is 292<br>
><br>
> ++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++<br>
> S. Miyamoto and P. A. Kollman<br>
> SETTLE: An Analytical Version of the SHAKE and RATTLE Algorithms for<br>
> Rigid<br>
> Water Models<br>
> J. Comp. Chem. 13 (1992) pp. 952-962<br>
> -------- -------- --- Thank You --- -------- --------<br>
><br>
> Center of mass motion removal mode is Linear<br>
> We have the following groups for center of mass motion removal:<br>
> 0: rest<br>
> There are: 22765 Atoms<br>
> Initial temperature: 299.915 K<br>
><br>
><br>
> Am 15/07/15 um 17:57 schrieb Shirts, Michael R. (mrs5pt):<br>
>>> There I also got a linear drift (but smaller) of 0.78 kJ/mol/ps<br>
>>> (3.436*10^-5 kJ/mol/ps per atom).<br>
>>> For comparison reasons I also did a NVT Nose-Hoover Simulation with<br>
>>> manually set rlist=1.012nm: There I got a comparable linear drift of<br>
>>> 0.67<br>
>>> kJ/mol/ps (2.94*10^-5 kJ/mol/ps per atom). So no differences between<br>
>>> NVE<br>
>>> and NVT so far in my opinion...<br>
>><br>
>> So sounds like the conserved quantity drift with NVT is not due to<br>
>> NH, but<br>
>> due to something else with the underlying dynamics.<br>
>><br>
>> Best,<br>
>> ~~~~~~~~~~~~<br>
>> Michael Shirts<br>
>> Associate Professor<br>
>> Department of Chemical Engineering<br>
>> University of Virginia<br>
>> <a href="mailto:michael.shirts@virginia.edu" target="_blank">michael.shirts@virginia.edu</a><br>
>> (434) 243-1821<br>
>><br>
>><br>
>><br>
>> On 7/15/15, 11:41 AM, "Bernhard" <<a href="mailto:b.reuter@uni-kassel.de" target="_blank">b.reuter@uni-kassel.de</a>> wrote:<br>
>><br>
>>> I mean a drift of the total energy in NVE - while with Nose-Hoover the<br>
>>> drift is in the Conserved-Energy quantity of g_energy (the total energy<br>
>>> shows no drift with Noose-Hoover...).<br>
>>><br>
>>> Am 15/07/15 um 17:38 schrieb Bernhard:<br>
>>>> I also did a NVE simulation with the same parameters, system and<br>
>>>> starting conditions but with manually set rlist=1.012nm (since<br>
>>>> verlet-buffer-drift doesnt work in NVE):<br>
>>>> There I also got a linear drift (but smaller) of 0.78 kJ/mol/ps<br>
>>>> (3.436*10^-5 kJ/mol/ps per atom).<br>
>>>> For comparison reasons I also did a NVT Nose-Hoover Simulation with<br>
>>>> manually set rlist=1.012nm:<br>
>>>> There I got a comparable linear drift of 0.67 kJ/mol/ps (2.94*10^-5<br>
>>>> kJ/mol/ps per atom).<br>
>>>> So no differences between NVE and NVT so far in my opinion...<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Best,<br>
>>>> Bernhard<br>
>>>><br>
>>>> Am 15/07/15 um 17:10 schrieb Shirts, Michael R. (mrs5pt):<br>
>>>>> The conserved quantity in nose-hoover is not quite as good as the<br>
>>>>> conserved energy, which should have no drift at all. For NH, the<br>
>>>>> conserved quantity should drift as a random Gaussian process with<br>
>>>>> mean<br>
>>>>> zero (i.e. go with sqrt(N)). It shouldn't be drifting linearly.<br>
>>>>><br>
>>>>> I would check to see if your system conserved energy when run with<br>
>>>>> NVE<br>
>>>>> (use the endpoint of the NPT simulation). It's easier to diagnose<br>
>>>>> any<br>
>>>>> problems with an NVE simulation, which should have virtually no<br>
>>>>> drift, vs<br>
>>>>> a NVT simulation, which has random noise drift. Odds are, if<br>
>>>>> there is<br>
>>>>> a<br>
>>>>> problem with the NVT simulation, it will also show up in the NVE<br>
>>>>> simulation if only the thermostat is removed.<br>
>>>>><br>
>>>>> Also, consider looking at<br>
>>>>> <a href="http://pubs.acs.org/doi/abs/10.1021/ct300688p" rel="noreferrer" target="_blank">http://pubs.acs.org/doi/abs/10.1021/ct300688p</a><br>
>>>>> for tests of whether the ensemble generated is correct.<br>
>>>>><br>
>>>>> Best,<br>
>>>>> ~~~~~~~~~~~~<br>
>>>>> Michael Shirts<br>
>>>>> Associate Professor<br>
>>>>> Department of Chemical Engineering<br>
>>>>> University of Virginia<br>
>>>>> <a href="mailto:michael.shirts@virginia.edu" target="_blank">michael.shirts@virginia.edu</a><br>
>>>>> (434) 243-1821<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On 7/15/15, 10:58 AM, "Bernhard" <<a href="mailto:b.reuter@uni-kassel.de" target="_blank">b.reuter@uni-kassel.de</a>> wrote:<br>
>>>>><br>
>>>>>> Dear Gromacs Users and Developers,<br>
>>>>>><br>
>>>>>> I have a problem regarding energy conservation in my 10ns NVT<br>
>>>>>> protein+water+ions (22765 atoms) production (minimization and<br>
>>>>>> equilibration for more than 15ns was carried out in NPT before)<br>
>>>>>> simulations using a Nose-Hoover thermostat (tau=2.5ps).<br>
>>>>>> On first glance everything looks fine - the potential, kinetic and<br>
>>>>>> total<br>
>>>>>> energy are nearly perfectly constant (with normal fluctuations) -<br>
>>>>>> but<br>
>>>>>> when I checked the "Conserved-Energy" quantity that g_energy<br>
>>>>>> outputs I<br>
>>>>>> had to recognize a significant (nearly perfectly) linear downward<br>
>>>>>> drift<br>
>>>>>> of this "to-be-conserved" quantity of around 1.7 kJ/mol/ps<br>
>>>>>> (7.48*10^-5<br>
>>>>>> kJ/mol/ps per atom).<br>
>>>>>> This appears somehow disturbing to me since I would expect that this<br>
>>>>>> Conserved-Energy is the conserved energy of the extended Nose-Hoover<br>
>>>>>> Hamiltonian - which should by definition be conserved.<br>
>>>>>><br>
>>>>>> If it would be a drift caused by normal round-off error due to<br>
>>>>>> single<br>
>>>>>> precision I would expect it to grow with Sqrt(N) and not with N<br>
>>>>>> (linear)<br>
>>>>>> (N=number of steps).<br>
>>>>>> So I would like to know if this is a normal behaviour and also what<br>
>>>>>> could cause this (buffer size, precision, constraints etc)?<br>
>>>>>> Also I would like to know, if I am correct with my guess that the<br>
>>>>>> "Conserved-Energy" quantity is in this case the energy of the<br>
>>>>>> extended<br>
>>>>>> Nose-Hoover Hamiltonian?<br>
>>>>>> The .mdp file is atatched (don't be confused about rlist=1 -<br>
>>>>>> since Im<br>
>>>>>> using the Verlet-scheme the verlet-buffer-drift option should be by<br>
>>>>>> default active and determine the rlist value (Verlet buffer-size)<br>
>>>>>> automatically).<br>
>>>>>><br>
>>>>>> Best regards,<br>
>>>>>> Bernhard<br>
>>>>>><br>
>>>>>> ; Run parameters<br>
>>>>>> integrator = md ; leap-frog integrator<br>
>>>>>> nsteps = 10000000 ; 10000 ps = 10 ns<br>
>>>>>> dt = 0.001 ; 1 fs<br>
>>>>>> ; Output control<br>
>>>>>> nstxout = 5000 ; save coordinates every ps<br>
>>>>>> nstvout = 5000 ; save velocities every ps<br>
>>>>>> nstxtcout = 1000 ; xtc compressed trajectory output<br>
>>>>>> every ps<br>
>>>>>> nstenergy = 1000 ; save energies every ps<br>
>>>>>> nstlog = 5000 ; update log file every ps<br>
>>>>>> ; Bond parameters<br>
>>>>>> continuation = yes ; continue from NPT<br>
>>>>>> constraint_algorithm = lincs ; holonomic constraints<br>
>>>>>> constraints = h-bonds ; all bonds (even heavy atom-H bonds)<br>
>>>>>> constrained<br>
>>>>>> lincs_iter = 1 ; accuracy of LINCS<br>
>>>>>> lincs_order = 4 ; also related to accuracy<br>
>>>>>> ; Neighborsearching<br>
>>>>>> cutoff-scheme = Verlet ; Verlet cutoff-scheme instead of<br>
>>>>>> group-scheme (no charge-groups used)<br>
>>>>>> ns_type = grid ; search neighboring grid cells<br>
>>>>>> nstlist = 10 ; 10 fs<br>
>>>>>> rlist = 1.0 ; short-range neighborlist cutoff (in nm)<br>
>>>>>> rcoulomb = 1.0 ; short-range electrostatic cutoff (in nm)<br>
>>>>>> rvdw = 1.0 ; short-range van der Waals cutoff (in nm)<br>
>>>>>> ; Electrostatics<br>
>>>>>> coulombtype = PME ; Particle Mesh Ewald for long-range<br>
>>>>>> electrostatics<br>
>>>>>> pme_order = 4 ; cubic interpolation<br>
>>>>>> fourierspacing = 0.12 ; grid spacing for FFT<br>
>>>>>> ; Temperature coupling is on<br>
>>>>>> tcoupl = nose-hoover ; modified Berendsen thermostat<br>
>>>>>> tc-grps = Protein Non-Protein ; two coupling groups - more<br>
>>>>>> accurate<br>
>>>>>> tau_t = 2.5 2.5 ; time constant, in ps<br>
>>>>>> ref_t = 300 300 ; reference temperature, one for each<br>
>>>>>> group, in K<br>
>>>>>> ; Pressure coupling is off<br>
>>>>>> pcoupl = no ; no pressure coupling in NVT<br>
>>>>>> ; Periodic boundary conditions<br>
>>>>>> pbc = xyz ; 3-D PBC<br>
>>>>>> ; Dispersion correction<br>
>>>>>> DispCorr = EnerPres ; account for cut-off vdW scheme<br>
>>>>>> ; Velocity generation<br>
>>>>>> gen_vel = no ; don¹t assign velocities from Maxwell<br>
>>>>>> distribution<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Gromacs Developers mailing list<br>
>>>>>><br>
>>>>>> * Please search the archive at<br>
>>>>>> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a><br>
>>>>>> before<br>
>>>>>> posting!<br>
>>>>>><br>
>>>>>> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
>>>>>><br>
>>>>>> * For (un)subscribe requests visit<br>
>>>>>><br>
>>>>>> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a><br>
>>>>>><br>
>>>>>> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
>>> --<br>
>>> Gromacs Developers mailing list<br>
>>><br>
>>> * Please search the archive at<br>
>>> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before<br>
>>> posting!<br>
>>><br>
>>> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
>>><br>
>>> * For (un)subscribe requests visit<br>
>>> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a><br>
>>> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
><br>
<br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>