[gmx-users] Interaction energy
Dear Gromacs users, i run dynamics for 20 ns and plot the interaction energy which i attached with this.. is this plot correct? Please suggest something Thank you kannan s -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] Interaction energy graph
Dear Gromacs users, i run dynamics for 20 ns and plot the interaction energy which i attached with this.. is this plot correct? Please suggest something Thank you kannan s india -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] Rigid water model
Hi! I tried to reproduce results for rigid water with 895 molecules~1000 kg/m3 density, 10 ns NPT simulation (298 K & 1 bar)with Parinello Rahman Barostat and Berendsen thermostat. Here is my result for SPC water Kappa (J/m3)5.689E-10 Cp 22.8054 Cp- Cv 5.94102 The density, diffusion coefficient, the average configuration energy agree with previous results. However the heat capacity value is quite low as compared to 75 J/mol K of real water or even that has been previously found with water models. I compared my values with a 2 ns and 10 ns simulations, but the heat capacity value shows no real improvement. I do not know much about quantum corrections hence I have not tried it. Will applying quantum corrections give the correct heat capacity? The isothermal compressibility reported by GROMACS is in J/m3 and the adiabatic bulk modulus is reported in m^3/J, could that be a mistake and should it be rather in (J/m^3)^-1 and J/m3 respectively. And, why does the isothermal compressibility change during the course of simulation if it has been fixed in the mdp file. Best wishes, Michelle -- View this message in context: http://gromacs.5086.x6.nabble.com/Rigid-water-model-tp5015158.html Sent from the GROMACS Users Forum mailing list archive at Nabble.com. -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] Position restraints
On 3/14/14, 4:28 PM, Nimmy McNimmerson wrote: I have a .top file looking like this: #include "spc.itp" #include "ffgmx.itp" #include "lipid.itp" #define POSRES_LIPID #include "mylipid.itp" #include "dppc.itp" [ system ] test system [ molecules ] ; Compound#mols DX5 200 DPPC200 The #define POSRES_LIPID is used to determine whether to include position restraints in mylipid.itp. However, when I try to run grompp on this (with everything the exact same as before I included the position restraints), I get the error "Topology include file "lipid_posre.itp" not found". If I take out all the position restraints, it works fine and grompp does what is expected. What's going on? I never asked to include this file, I don't even know what lipid_posre.itp is and google has no results on it. I tried adding #include "lipid_posre.itp" at the top of the .top file, just to see what happened, but I got the same error. How am I supposed to add position restraints? The GROMACS manual just says to add them and doesn't mention additional includes, and I added them in the same way that the manual said to. You did ask to #include the position restraints because you're explicitly using #define to set the inclusion conditions to be true. If you don't know what's calling "lipid_posre.itp," that's what grep is for. It's probably dppc.itp, which includes the option to restrain the lipids under a conditional #ifdef POSRES_LIPID. Your topology says "turn on lipid restraints," and one of the lipid .itp files (again, probably dppc.itp) says "if lipid restraints are turned on, #include "lipid_posre.itp." Remove the #define statement from the topology; that's not normal use (technically correct in terms of syntax, but then it's always true, which is probably not what you want) and instead use "define -DPOSRES_LIPID" in the .mdp file to conditionally trigger the restraints. -Justin -- == Justin A. Lemkul, Ph.D. Ruth L. Kirschstein NRSA Postdoctoral Fellow Department of Pharmaceutical Sciences School of Pharmacy Health Sciences Facility II, Room 601 University of Maryland, Baltimore 20 Penn St. Baltimore, MD 21201 jalem...@outerbanks.umaryland.edu | (410) 706-7441 http://mackerell.umaryland.edu/~jalemkul == -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] Position restraints
I have a .top file looking like this: #include "spc.itp" #include "ffgmx.itp" #include "lipid.itp" #define POSRES_LIPID #include "mylipid.itp" #include "dppc.itp" [ system ] test system [ molecules ] ; Compound #mols DX5 200 DPPC 200 The #define POSRES_LIPID is used to determine whether to include position restraints in mylipid.itp. However, when I try to run grompp on this (with everything the exact same as before I included the position restraints), I get the error "Topology include file "lipid_posre.itp" not found". If I take out all the position restraints, it works fine and grompp does what is expected. What's going on? I never asked to include this file, I don't even know what lipid_posre.itp is and google has no results on it. I tried adding #include "lipid_posre.itp" at the top of the .top file, just to see what happened, but I got the same error. How am I supposed to add position restraints? The GROMACS manual just says to add them and doesn't mention additional includes, and I added them in the same way that the manual said to. -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] Free energy calculation of a charged system
Hi Valentina - Honestly, I did not get the considerations with charges. TI probably scales interaction energies between selected groups, not charges. Science-wise, I would first decouple organic particle, then decouple chloride anions, and place a right sign between these two free energies. If you substitute an ion in the neutral system by a molecule, your system free energy will not definitely like this giving a positive (delta)G. Dr. Vitaly V. Chaban On Fri, Mar 14, 2014 at 4:52 PM, Valentina wrote: > Hello, > > I need an advise on how it is better to approach the ThermoD integration of > such system: > +vely charged inorganic layer, filled with water and counterbalanced by -ve > organics > > Do I integrate out organics both VdW and Coulomb, making the system have > total +ve charge at lambda = 1 > > OR: > > Do I integrate out organics only by VdW, leaving Couloumb interactions, by > such having a neutral system at lambda = 1 > > I ideally want to compare the free energies of the substituting Cl- ions > with organic molecules, but I don't think I can just change Cl- at lambda =0 > for an organics at lambda =1 (or can I?) Therefore I was planning to perform > Thermod integration of both systems independently, also Cl- and organics in > vacuum (again charges issue) and calculate partition ratios. > > Thank you for advise, > V > > -- > View this message in context: > http://gromacs.5086.x6.nabble.com/Free-energy-calculation-of-a-charged-system-tp5015154.html > Sent from the GROMACS Users Forum mailing list archive at Nabble.com. > -- > Gromacs Users mailing list > > * Please search the archive at > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > > * For (un)subscribe requests visit > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a > mail to gmx-users-requ...@gromacs.org. -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] Free energy calculation of a charged system
Hello, I need an advise on how it is better to approach the ThermoD integration of such system: +vely charged inorganic layer, filled with water and counterbalanced by -ve organics Do I integrate out organics both VdW and Coulomb, making the system have total +ve charge at lambda = 1 OR: Do I integrate out organics only by VdW, leaving Couloumb interactions, by such having a neutral system at lambda = 1 I ideally want to compare the free energies of the substituting Cl- ions with organic molecules, but I don't think I can just change Cl- at lambda =0 for an organics at lambda =1 (or can I?) Therefore I was planning to perform Thermod integration of both systems independently, also Cl- and organics in vacuum (again charges issue) and calculate partition ratios. Thank you for advise, V -- View this message in context: http://gromacs.5086.x6.nabble.com/Free-energy-calculation-of-a-charged-system-tp5015154.html Sent from the GROMACS Users Forum mailing list archive at Nabble.com. -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] g_tune_pme scalevdw option not working?
Checked. Fixed. Thanks again! João 2014-03-14 14:03 GMT+01:00 João Rodrigues : > Hi Carsten, > > Thanks for the fix! > > Will run it today and get back to you with the results. > > Cheers, > > João > > > 2014-03-14 12:32 GMT+01:00 Carsten Kutzner : > > Dear João, >> >> could you check whether >> >> https://gerrit.gromacs.org/#/c/3267/ >> >> fixes your problems with g_tune_pme? >> >> Thanks, >> Carsten >> >> >> >> On 13 Mar 2014, at 18:27, João Rodrigues wrote: >> >> > Hi Carsten, >> > >> > Thanks for the reply and for the info on the rlist modification. >> > >> > I created the bug report - http://redmine.gromacs.org/issues/1460 - and >> > assigned it to you. I also set the priority to low, don't know if it >> > matters. >> > >> > Cheers, >> > >> > João >> > >> > >> > 2014-03-13 18:04 GMT+01:00 Carsten Kutzner : >> > >> >> Dear João, >> >> >> >> On 13 Mar 2014, at 14:38, João Rodrigues wrote: >> >> >> >>> Hi all, >> >>> >> >>> I've been playing with g_tune_pme (neat tool!) for the last couple of >> >> days. >> >>> If I understood correctly, it can also be used to iterate over >> different >> >>> rcoulomb values using the -rmin and -rmax options. Using the Verlet >> >> scheme >> >>> requires rvdw = rcoulomb, so I used the -scalevdw option (which >> should be >> >>> true by default) to keep these equal. This does not seem to happen.. >> >>> >> >>> The (partial) contents of a tpr file of such a failed run show the >> >>> following: >> >>> >> >>> verlet-buffer-drift = 0.005 >> >>> * rlist= 1.213* >> >>> rlistlong= 1.213 >> >>> nstcalclr= 15 >> >>> rtpi = 0.05 >> >>> coulombtype = PME >> >>> coulomb-modifier = Potential-shift >> >>> rcoulomb-switch = 0 >> >>> * rcoulomb = 1* >> >>> vdwtype = Cut-off >> >>> vdw-modifier = Potential-shift >> >>> rvdw-switch = 0 >> >>> * rvdw = 1.2* >> >>> >> >>> The original mdp has the following parameters: >> >>> >> >>> ; Neighborsearching >> >>> ns_type = grid ; search neighboring grid cels >> >>> nstlist = 15; 10 fs >> >>> *rlist = 1.2 ; short-range neighborlist cutoff (in >> >> nm)* >> >>> *rcoulomb= 1.2 ; short-range electrostatic cutoff >> (in >> >> nm)* >> >>> *rvdw= 1.2 ; short-range van der Waals cutoff >> (in >> >> nm)* >> >>> cutoff-scheme = Verlet >> >>> >> >>> ; Electrostatics >> >>> coulombtype = PME ; Particle Mesh Ewald for long-range >> >>> electrostatics >> >>> pme_order = 4 ; cubic interpolation >> >>> fourierspacing = 0.16 ; grid spacing for FFT >> >>> >> >>> I searched a bit in the source code of gmx_tune_pme.c (4.6.5) and >> found >> >>> that the only check done between these parameters (rvdw and rcoulomb) >> is >> >> if >> >>> rvdw != rcoulomb in the original file, keep them as is (line 875). >> Other >> >>> than that, rvdw is checked against rlist to ensure that it keeps the >> >>> highest value of the two (rvdw >= rlist) (line 1012). This seems to >> make >> >>> sense since rlist was modified based on rcoulomb, in case of plain PME >> >>> (line 1004). However, this only ensures both values are equal if the >> new >> >>> rcoulomb is larger than the original. In case we start with rcoulomb >> 1.2 >> >>> and ask g_tune_pme to range from 1.0 to 1.4, those below 1.2 will >> fail. >> >> You are right, this is a bug in g_tune_pme. Could you please file this >> >> issue in http://redmine.gromacs.org and put me as assignee? >> >> >> >> Thanks for reporting this! >> >> >> >>> Also, why is my rlist changing since it is equal to rcoulomb? It >> should >> >> be >> >>> kept the same (line 1004) right? >> >> This is a feature of the Verlet scheme, see >> >> http://www.gromacs.org/Documentation/Cut-off_schemes >> >> >> >> Best, >> >> Carsten >> >> >> >> >> >> >> >> >> >> -- >> >> Dr. Carsten Kutzner >> >> Max Planck Institute for Biophysical Chemistry >> >> Theoretical and Computational Biophysics >> >> Am Fassberg 11, 37077 Goettingen, Germany >> >> Tel. +49-551-2012313, Fax: +49-551-2012302 >> >> http://www.mpibpc.mpg.de/grubmueller/kutzner >> >> http://www.mpibpc.mpg.de/grubmueller/sppexa >> >> -- >> >> Gromacs Users mailing list >> >> >> >> * Please search the archive at >> >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before >> >> posting! >> >> >> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists >> >> >> >> * For (un)subscribe requests visit >> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or >> >> send a mail to gmx-users-requ...@gromacs.org. >> >> >> > -- >> > Gromacs Users mailing list >> > >> > * Please search the archive at >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before >> posting! >> > >> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists >> > >> > * For (un)subscribe requests visit >> > htt
Re: [gmx-users] Dubious results with NPT
Hello Mark, I guess you were asking whether I ran the simulation as a continuation to a previous 5ns run? But the results I got are from a continuous 10ns simulation. Sujith. On Fri, Mar 14, 2014 at 4:28 PM, Mark Abraham wrote: > The simplest explanation would be that you've appended to a previous 5ns > trajectory, not run a new trajectory. Check the .log file and the length of > time you expected this job to run (wall and simulation). > > Mark > > > On Fri, Mar 14, 2014 at 9:02 AM, sujithkakkat . >wrote: > > > Hello, > > > > This time I tried sesiisotropic scaling with Berendsen Barostat. The > > compressibility was set to zero in Z-direction allowing scaling only in X > > and Y. The NPT simulation was run for 10ns. > > The result did not look good and the average pressure was ~36 bar > > (reference pressure is 1 bar). > > Even more confusing was the graphs of various properties against time. > > Pressure vs time shows a sudden decrease in fluctuations at about 5ns and > > thereafter . The pressure fluctuations lowered to around ~170bar from > ~650 > > bar. > > A dramatic change was observed in many properties at around this time. > For > > eg, the short range LJ interaction was found to decrease sharply at ~5ns. > > Also, total energy, Kinetic, Potential energies and the temperature > showed > > a rapid drop in the magnitude of their fluctuations from the same time. > > > > Nothing notable was observed in the system trajectory at around this > > time. I am totally confused, and I feel that I made some very bad choice > > again the MDP file given below. > > Please let me know what you think. Suggest something on this issue > which I > > should read about. > > > > > > ; 7.3.3 Run Control > > integrator = md > > tinit = 0 > > dt = 0.001 > > nsteps = 1000 > > comm_mode = Linear > > nstcomm = 1 > > comm_grps = CHX SOL > > > > ; 7.3.8 Output Control > > nstxout = 25000 > > nstvout = 25000 > > nstfout = 25000 > > nstlog = 100 > > nstenergy = 100 > > nstxtcout = 100 > > xtc_precision = 1000 > > xtc_grps = System > > energygrps = System > > > > ; 7.3.9 Neighbor Searching > > nstlist= 10 > > ns_type = grid > > pbc = xyz > > rlist = 0.9 > > > > ; 7.3.10 Electrostatics > > coulombtype = PME > > rcoulomb = 0.9 > > > > ; 7.3.11 VdW > > vdwtype = cut-off > > rvdw = 1.4 > > DispCorr = EnerPres > > > > ; 7.3.13 Ewald > > fourierspacing = 0.12 > > pme_order = 4 > > ewald_rtol= 1e-5 > > > > ; 7.3.14 Temperature Coupling > > tcoupl = nose-hoover > > tc_grps = CHXSOL > > tau_t = 0.50.5 > > ref_t = 298298 > > > > ; 7.3.15 Pressure Coupling > > pcoupl = berendsen > > pcoupltype = semiisotropic > > tau_p = 2.0 > > > > compressibility= 4.5e-5 0.0 > > ref_p = 1.01.0 > > > > > > ; 7.3.17 Velocity Generation > > gen_vel = no > > gen_temp= 298 > > gen_seed = -1 > > > > ; 7.3.18 Bonds > > constraints = none > > constraint_algorithm= LINCS > > continuation= no > > lincs_order = 4 > > lincs_iter = 1 > > lincs_warnangle = 30 > > > > > > > > Regards, > > Sujith. > > > > > > On Wed, Mar 12, 2014 at 5:28 PM, Justin Lemkul wrote: > > > > > > > > > > > On 3/12/14, 7:51 AM, sujithkakkat . wrote: > > > > > >> Hello, > > >> > > >> After a while I got back to the problem posted here. This issue was > > the > > >> large value for average pressure(~25 bar against the reference > pressure > > >> of > > >> 1 bar) in NPT simulations with parrinello rahman barostat. The system > > >> studied is cyclohexane-water system with an interface. > > >> The forcefield is Gromos96. Gromacs 4.6.5 version is used. > > >> > > >> I recollect a post from Michael Shirts which says that with systems > that > > >> are heterogeneous in direction (not uniform in x y and z), any errors > in > > >> the pressure may be magnified. Is this what is happening in my case? > > >> > > >> Based on your suggestions , I tried the following to analyze/solve the > > >> problem, and till now the results have not improved a bit. > > >> > > >> (i) The system was simplified. Each phases was simulated separately. > > The > > >> results were good, with proper values of average pressure after NPT > > >> simulation for both independent water and cyclohexane systems. > However, > > >> when doing the same with sim
Re: [gmx-users] g_tune_pme scalevdw option not working?
Hi Carsten, Thanks for the fix! Will run it today and get back to you with the results. Cheers, João 2014-03-14 12:32 GMT+01:00 Carsten Kutzner : > Dear João, > > could you check whether > > https://gerrit.gromacs.org/#/c/3267/ > > fixes your problems with g_tune_pme? > > Thanks, > Carsten > > > > On 13 Mar 2014, at 18:27, João Rodrigues wrote: > > > Hi Carsten, > > > > Thanks for the reply and for the info on the rlist modification. > > > > I created the bug report - http://redmine.gromacs.org/issues/1460 - and > > assigned it to you. I also set the priority to low, don't know if it > > matters. > > > > Cheers, > > > > João > > > > > > 2014-03-13 18:04 GMT+01:00 Carsten Kutzner : > > > >> Dear João, > >> > >> On 13 Mar 2014, at 14:38, João Rodrigues wrote: > >> > >>> Hi all, > >>> > >>> I've been playing with g_tune_pme (neat tool!) for the last couple of > >> days. > >>> If I understood correctly, it can also be used to iterate over > different > >>> rcoulomb values using the -rmin and -rmax options. Using the Verlet > >> scheme > >>> requires rvdw = rcoulomb, so I used the -scalevdw option (which should > be > >>> true by default) to keep these equal. This does not seem to happen.. > >>> > >>> The (partial) contents of a tpr file of such a failed run show the > >>> following: > >>> > >>> verlet-buffer-drift = 0.005 > >>> * rlist= 1.213* > >>> rlistlong= 1.213 > >>> nstcalclr= 15 > >>> rtpi = 0.05 > >>> coulombtype = PME > >>> coulomb-modifier = Potential-shift > >>> rcoulomb-switch = 0 > >>> * rcoulomb = 1* > >>> vdwtype = Cut-off > >>> vdw-modifier = Potential-shift > >>> rvdw-switch = 0 > >>> * rvdw = 1.2* > >>> > >>> The original mdp has the following parameters: > >>> > >>> ; Neighborsearching > >>> ns_type = grid ; search neighboring grid cels > >>> nstlist = 15; 10 fs > >>> *rlist = 1.2 ; short-range neighborlist cutoff (in > >> nm)* > >>> *rcoulomb= 1.2 ; short-range electrostatic cutoff (in > >> nm)* > >>> *rvdw= 1.2 ; short-range van der Waals cutoff (in > >> nm)* > >>> cutoff-scheme = Verlet > >>> > >>> ; Electrostatics > >>> coulombtype = PME ; Particle Mesh Ewald for long-range > >>> electrostatics > >>> pme_order = 4 ; cubic interpolation > >>> fourierspacing = 0.16 ; grid spacing for FFT > >>> > >>> I searched a bit in the source code of gmx_tune_pme.c (4.6.5) and found > >>> that the only check done between these parameters (rvdw and rcoulomb) > is > >> if > >>> rvdw != rcoulomb in the original file, keep them as is (line 875). > Other > >>> than that, rvdw is checked against rlist to ensure that it keeps the > >>> highest value of the two (rvdw >= rlist) (line 1012). This seems to > make > >>> sense since rlist was modified based on rcoulomb, in case of plain PME > >>> (line 1004). However, this only ensures both values are equal if the > new > >>> rcoulomb is larger than the original. In case we start with rcoulomb > 1.2 > >>> and ask g_tune_pme to range from 1.0 to 1.4, those below 1.2 will fail. > >> You are right, this is a bug in g_tune_pme. Could you please file this > >> issue in http://redmine.gromacs.org and put me as assignee? > >> > >> Thanks for reporting this! > >> > >>> Also, why is my rlist changing since it is equal to rcoulomb? It should > >> be > >>> kept the same (line 1004) right? > >> This is a feature of the Verlet scheme, see > >> http://www.gromacs.org/Documentation/Cut-off_schemes > >> > >> Best, > >> Carsten > >> > >> > >> > >> > >> -- > >> Dr. Carsten Kutzner > >> Max Planck Institute for Biophysical Chemistry > >> Theoretical and Computational Biophysics > >> Am Fassberg 11, 37077 Goettingen, Germany > >> Tel. +49-551-2012313, Fax: +49-551-2012302 > >> http://www.mpibpc.mpg.de/grubmueller/kutzner > >> http://www.mpibpc.mpg.de/grubmueller/sppexa > >> -- > >> Gromacs Users mailing list > >> > >> * Please search the archive at > >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before > >> posting! > >> > >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > >> > >> * For (un)subscribe requests visit > >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or > >> send a mail to gmx-users-requ...@gromacs.org. > >> > > -- > > Gromacs Users mailing list > > > > * Please search the archive at > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before > posting! > > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > > > > * For (un)subscribe requests visit > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or > send a mail to gmx-users-requ...@gromacs.org. > > -- > Gromacs Users mailing list > > * Please search the archive at > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before > postin
Re: [gmx-users] asking for N and C termini for DNA and giving error
On 3/14/14, 7:05 AM, Sucharita Dey wrote: Hello, My protein is pr-DNA complex, it is identifying DNA terminus and searching for N and C in tdb file giving error. When I select -ter and specify none as termini , it still gives error saying "There is a dangling bond at at least one of the terminal ends. Fix your coordinate file, add a new terminal database entry (.tdb), or select the proper existing terminal entry. " Please help. Error without -ter option: Processing chain 1 'B' (434 atoms, 21 residues) Identified residue DADE1 as a starting terminus. Identified residue DTHY21 as a ending terminus. 8 out of 8 lines of specbond.dat converted successfully Start terminus DADE-1: NH3+ End terminus DTHY-21: COO- --- Program pdb2gmx, VERSION 4.6.3 Source code file: /home/sucharita/sucharita/softwares/gromacs_all/gromacs-4.6.3/src/kernel/pdb2top.c, line: 1148 Fatal error: atom N not found in buiding block 1DADE while combining tdb and rtp For more information and tips for troubleshooting, please check the GROMACS website at http://www.gromacs.org/Documentation/Errors with -ter option selecting none Processing chain 1 'B' (434 atoms, 21 residues) Identified residue DADE1 as a starting terminus. Identified residue DTHY21 as a ending terminus. 8 out of 8 lines of specbond.dat converted successfully Select start terminus type for DADE-1 0: NH3+ 1: NH2 2: None 2 Start terminus DADE-1: None Select end terminus type for DTHY-21 0: COO- 1: COOH 2: None 2 End terminus DTHY-21: None --- Program pdb2gmx, VERSION 4.6.3 Source code file: /home/sucharita/sucharita/softwares/gromacs_all/gromacs-4.6.3/src/kernel/pdb2top.c, line: 1109 Fatal error: There is a dangling bond at at least one of the terminal ends. Fix your coordinate file, add a new terminal database entry (.tdb), or select the proper existing terminal entry. For more information and tips for troubleshooting, please check the GROMACS website at http://www.gromacs.org/Documentation/Errors --- Sucharita Dey,PhD, Research Fellow, Cancer Science Institute of Singapore, National University of Singapore. 14, Medical Drive, #12-01, Singapore 117599. Tel: (65) 90355220, email: cs...@nus.edu.sg The problem is that DADE, DTHY, etc. are not recognized as normal residue names for anything, since they are not defined in residuetypes.dat as being DNA, so Gromacs assumes they are protein. -Justin -- == Justin A. Lemkul, Ph.D. Ruth L. Kirschstein NRSA Postdoctoral Fellow Department of Pharmaceutical Sciences School of Pharmacy Health Sciences Facility II, Room 601 University of Maryland, Baltimore 20 Penn St. Baltimore, MD 21201 jalem...@outerbanks.umaryland.edu | (410) 706-7441 http://mackerell.umaryland.edu/~jalemkul == -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] g_tune_pme scalevdw option not working?
Dear João, could you check whether https://gerrit.gromacs.org/#/c/3267/ fixes your problems with g_tune_pme? Thanks, Carsten On 13 Mar 2014, at 18:27, João Rodrigues wrote: > Hi Carsten, > > Thanks for the reply and for the info on the rlist modification. > > I created the bug report - http://redmine.gromacs.org/issues/1460 - and > assigned it to you. I also set the priority to low, don't know if it > matters. > > Cheers, > > João > > > 2014-03-13 18:04 GMT+01:00 Carsten Kutzner : > >> Dear João, >> >> On 13 Mar 2014, at 14:38, João Rodrigues wrote: >> >>> Hi all, >>> >>> I've been playing with g_tune_pme (neat tool!) for the last couple of >> days. >>> If I understood correctly, it can also be used to iterate over different >>> rcoulomb values using the -rmin and -rmax options. Using the Verlet >> scheme >>> requires rvdw = rcoulomb, so I used the -scalevdw option (which should be >>> true by default) to keep these equal. This does not seem to happen.. >>> >>> The (partial) contents of a tpr file of such a failed run show the >>> following: >>> >>> verlet-buffer-drift = 0.005 >>> * rlist= 1.213* >>> rlistlong= 1.213 >>> nstcalclr= 15 >>> rtpi = 0.05 >>> coulombtype = PME >>> coulomb-modifier = Potential-shift >>> rcoulomb-switch = 0 >>> * rcoulomb = 1* >>> vdwtype = Cut-off >>> vdw-modifier = Potential-shift >>> rvdw-switch = 0 >>> * rvdw = 1.2* >>> >>> The original mdp has the following parameters: >>> >>> ; Neighborsearching >>> ns_type = grid ; search neighboring grid cels >>> nstlist = 15; 10 fs >>> *rlist = 1.2 ; short-range neighborlist cutoff (in >> nm)* >>> *rcoulomb= 1.2 ; short-range electrostatic cutoff (in >> nm)* >>> *rvdw= 1.2 ; short-range van der Waals cutoff (in >> nm)* >>> cutoff-scheme = Verlet >>> >>> ; Electrostatics >>> coulombtype = PME ; Particle Mesh Ewald for long-range >>> electrostatics >>> pme_order = 4 ; cubic interpolation >>> fourierspacing = 0.16 ; grid spacing for FFT >>> >>> I searched a bit in the source code of gmx_tune_pme.c (4.6.5) and found >>> that the only check done between these parameters (rvdw and rcoulomb) is >> if >>> rvdw != rcoulomb in the original file, keep them as is (line 875). Other >>> than that, rvdw is checked against rlist to ensure that it keeps the >>> highest value of the two (rvdw >= rlist) (line 1012). This seems to make >>> sense since rlist was modified based on rcoulomb, in case of plain PME >>> (line 1004). However, this only ensures both values are equal if the new >>> rcoulomb is larger than the original. In case we start with rcoulomb 1.2 >>> and ask g_tune_pme to range from 1.0 to 1.4, those below 1.2 will fail. >> You are right, this is a bug in g_tune_pme. Could you please file this >> issue in http://redmine.gromacs.org and put me as assignee? >> >> Thanks for reporting this! >> >>> Also, why is my rlist changing since it is equal to rcoulomb? It should >> be >>> kept the same (line 1004) right? >> This is a feature of the Verlet scheme, see >> http://www.gromacs.org/Documentation/Cut-off_schemes >> >> Best, >> Carsten >> >> >> >> >> -- >> Dr. Carsten Kutzner >> Max Planck Institute for Biophysical Chemistry >> Theoretical and Computational Biophysics >> Am Fassberg 11, 37077 Goettingen, Germany >> Tel. +49-551-2012313, Fax: +49-551-2012302 >> http://www.mpibpc.mpg.de/grubmueller/kutzner >> http://www.mpibpc.mpg.de/grubmueller/sppexa >> -- >> Gromacs Users mailing list >> >> * Please search the archive at >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before >> posting! >> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists >> >> * For (un)subscribe requests visit >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or >> send a mail to gmx-users-requ...@gromacs.org. >> > -- > Gromacs Users mailing list > > * Please search the archive at > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > > * For (un)subscribe requests visit > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a > mail to gmx-users-requ...@gromacs.org. -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] asking for N and C termini for DNA and giving error
Hello, My protein is pr-DNA complex, it is identifying DNA terminus and searching for N and C in tdb file giving error. When I select -ter and specify none as termini , it still gives error saying "There is a dangling bond at at least one of the terminal ends. Fix your coordinate file, add a new terminal database entry (.tdb), or select the proper existing terminal entry. " Please help. Error without -ter option: Processing chain 1 'B' (434 atoms, 21 residues) Identified residue DADE1 as a starting terminus. Identified residue DTHY21 as a ending terminus. 8 out of 8 lines of specbond.dat converted successfully Start terminus DADE-1: NH3+ End terminus DTHY-21: COO- --- Program pdb2gmx, VERSION 4.6.3 Source code file: /home/sucharita/sucharita/softwares/gromacs_all/gromacs-4.6.3/src/kernel/pdb2top.c, line: 1148 Fatal error: atom N not found in buiding block 1DADE while combining tdb and rtp For more information and tips for troubleshooting, please check the GROMACS website at http://www.gromacs.org/Documentation/Errors with -ter option selecting none Processing chain 1 'B' (434 atoms, 21 residues) Identified residue DADE1 as a starting terminus. Identified residue DTHY21 as a ending terminus. 8 out of 8 lines of specbond.dat converted successfully Select start terminus type for DADE-1 0: NH3+ 1: NH2 2: None 2 Start terminus DADE-1: None Select end terminus type for DTHY-21 0: COO- 1: COOH 2: None 2 End terminus DTHY-21: None --- Program pdb2gmx, VERSION 4.6.3 Source code file: /home/sucharita/sucharita/softwares/gromacs_all/gromacs-4.6.3/src/kernel/pdb2top.c, line: 1109 Fatal error: There is a dangling bond at at least one of the terminal ends. Fix your coordinate file, add a new terminal database entry (.tdb), or select the proper existing terminal entry. For more information and tips for troubleshooting, please check the GROMACS website at http://www.gromacs.org/Documentation/Errors --- Sucharita Dey,PhD, Research Fellow, Cancer Science Institute of Singapore, National University of Singapore. 14, Medical Drive, #12-01, Singapore 117599. Tel: (65) 90355220, email: cs...@nus.edu.sg -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] Dubious results with NPT
The simplest explanation would be that you've appended to a previous 5ns trajectory, not run a new trajectory. Check the .log file and the length of time you expected this job to run (wall and simulation). Mark On Fri, Mar 14, 2014 at 9:02 AM, sujithkakkat . wrote: > Hello, > > This time I tried sesiisotropic scaling with Berendsen Barostat. The > compressibility was set to zero in Z-direction allowing scaling only in X > and Y. The NPT simulation was run for 10ns. > The result did not look good and the average pressure was ~36 bar > (reference pressure is 1 bar). > Even more confusing was the graphs of various properties against time. > Pressure vs time shows a sudden decrease in fluctuations at about 5ns and > thereafter . The pressure fluctuations lowered to around ~170bar from ~650 > bar. > A dramatic change was observed in many properties at around this time. For > eg, the short range LJ interaction was found to decrease sharply at ~5ns. > Also, total energy, Kinetic, Potential energies and the temperature showed > a rapid drop in the magnitude of their fluctuations from the same time. > > Nothing notable was observed in the system trajectory at around this > time. I am totally confused, and I feel that I made some very bad choice > again the MDP file given below. > Please let me know what you think. Suggest something on this issue which I > should read about. > > > ; 7.3.3 Run Control > integrator = md > tinit = 0 > dt = 0.001 > nsteps = 1000 > comm_mode = Linear > nstcomm = 1 > comm_grps = CHX SOL > > ; 7.3.8 Output Control > nstxout = 25000 > nstvout = 25000 > nstfout = 25000 > nstlog = 100 > nstenergy = 100 > nstxtcout = 100 > xtc_precision = 1000 > xtc_grps = System > energygrps = System > > ; 7.3.9 Neighbor Searching > nstlist= 10 > ns_type = grid > pbc = xyz > rlist = 0.9 > > ; 7.3.10 Electrostatics > coulombtype = PME > rcoulomb = 0.9 > > ; 7.3.11 VdW > vdwtype = cut-off > rvdw = 1.4 > DispCorr = EnerPres > > ; 7.3.13 Ewald > fourierspacing = 0.12 > pme_order = 4 > ewald_rtol= 1e-5 > > ; 7.3.14 Temperature Coupling > tcoupl = nose-hoover > tc_grps = CHXSOL > tau_t = 0.50.5 > ref_t = 298298 > > ; 7.3.15 Pressure Coupling > pcoupl = berendsen > pcoupltype = semiisotropic > tau_p = 2.0 > > compressibility= 4.5e-5 0.0 > ref_p = 1.01.0 > > > ; 7.3.17 Velocity Generation > gen_vel = no > gen_temp= 298 > gen_seed = -1 > > ; 7.3.18 Bonds > constraints = none > constraint_algorithm= LINCS > continuation= no > lincs_order = 4 > lincs_iter = 1 > lincs_warnangle = 30 > > > > Regards, > Sujith. > > > On Wed, Mar 12, 2014 at 5:28 PM, Justin Lemkul wrote: > > > > > > > On 3/12/14, 7:51 AM, sujithkakkat . wrote: > > > >> Hello, > >> > >> After a while I got back to the problem posted here. This issue was > the > >> large value for average pressure(~25 bar against the reference pressure > >> of > >> 1 bar) in NPT simulations with parrinello rahman barostat. The system > >> studied is cyclohexane-water system with an interface. > >> The forcefield is Gromos96. Gromacs 4.6.5 version is used. > >> > >> I recollect a post from Michael Shirts which says that with systems that > >> are heterogeneous in direction (not uniform in x y and z), any errors in > >> the pressure may be magnified. Is this what is happening in my case? > >> > >> Based on your suggestions , I tried the following to analyze/solve the > >> problem, and till now the results have not improved a bit. > >> > >> (i) The system was simplified. Each phases was simulated separately. > The > >> results were good, with proper values of average pressure after NPT > >> simulation for both independent water and cyclohexane systems. However, > >> when doing the same with similar parameters on the water-cyclohexane > >> combined system with parrinello-rahman barostat , still gives very high > >> average pressure (even after 10ns ) > >> > >> (ii) Changing the tau_p values did not help either. (I tried 1ps, 2ps, > >> and 4ps) > >> > >> My question is whether, I can try the semiisotropic scaling? The manual > >> says that it is useful in case of systems with interface. I am not > sure, > >> since none of the replies I got suggested that option, which gives the > >> impression that it i
Re: [gmx-users] multi threading on rocks cluster
On Fri, Mar 14, 2014 at 10:46 AM, michael.b wrote: > > dear all, > I have a problem with multithreading on a cluster. > Our (vanilla) rocks cluster has several nodes each with 8 cores. I used to > be > able to start a job with "mdrun_d -nt 8" (NOT mdrun_mpi) and the directive > "-pe mpi_smp 8" in the qsub job file, and the calculations would > automatically > be distributed over the eight cores in a single node. > So, what has changed? > Now judging from the speed of calculations, it seems as if only one core > was > used, but in the log file there is a statement: "Using 8 MPI threads" ... > is > there any > way to make sure that all cores are used, and is there a way to check how > many cores are really used by a given job? > Using top or htop is a good start. You should see an mdrun process per core, and nothing else significant going on. You should also inspect the log file for mdrun complaining about thread affinities, which it will manage correctly itself unless it detects external management, which it will respect. Likewise with managing the number of OpenMP threads per process. > thanks! > michael > > ps: I used a tpr file made with grompp version 4.6.5 and the mdrun on the > cluster > is actually 4.6.3 ... mdrun does not complain, but can this be the problem? > No. pps: i found that when using "cutoff-scheme = Verlet" in the mdp file the > jobs > run faster than otherwise, but even then they are slower than > expected ... > That's probably OpenMP partly saving the situation. This suggests there's some external process competing for the cpu(s), which top will show. > ppps: i these runs i do not use PME, but cut-off for electrostatics, does > this > perhaps affect multi-threading? > No, but it does affect whether your problem is worth solving ;-) Mark > > > > -- > View this message in context: > http://gromacs.5086.x6.nabble.com/multi-threading-on-rocks-cluster-tp5015146.html > Sent from the GROMACS Users Forum mailing list archive at Nabble.com. > -- > Gromacs Users mailing list > > * Please search the archive at > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before > posting! > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > > * For (un)subscribe requests visit > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or > send a mail to gmx-users-requ...@gromacs.org. > -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] g_potential
Dear List, I was looking for previous mailing list but I didn't get a straight forward answer. Can I use g_potential to calculate the electric field vector* at a single site at every snapshot of an MD ** trajectory e.g. *amide proton of Threonine residue? Many thanks, Neha -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] multi threading on rocks cluster
dear all, I have a problem with multithreading on a cluster. Our (vanilla) rocks cluster has several nodes each with 8 cores. I used to be able to start a job with "mdrun_d -nt 8" (NOT mdrun_mpi) and the directive "-pe mpi_smp 8" in the qsub job file, and the calculations would automatically be distributed over the eight cores in a single node. Now judging from the speed of calculations, it seems as if only one core was used, but in the log file there is a statement: "Using 8 MPI threads" ... is there any way to make sure that all cores are used, and is there a way to check how many cores are really used by a given job? thanks! michael ps: I used a tpr file made with grompp version 4.6.5 and the mdrun on the cluster is actually 4.6.3 ... mdrun does not complain, but can this be the problem? pps: i found that when using "cutoff-scheme = Verlet" in the mdp file the jobs run faster than otherwise, but even then they are slower than expected ... ppps: i these runs i do not use PME, but cut-off for electrostatics, does this perhaps affect multi-threading? -- View this message in context: http://gromacs.5086.x6.nabble.com/multi-threading-on-rocks-cluster-tp5015146.html Sent from the GROMACS Users Forum mailing list archive at Nabble.com. -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] genion
Dear Andrew, First of all you just have a look at the "*Ions.itp" *file, which exists in "gromacs-4.5.2/share/top/(any forcefield you are working with)" in your installed directory. There you will find all types of *Ions* we can use. Regarding *genion tool, *this command should work: "*genion -s ions.tpr -o Solv_ions.gro -p topol.top -pname ZN -np 5" *-- for random placement of ions "*genion -norandom -s ions.tpr -o Solv_ions.gro -p topol.top -pname ZN -np 5" * --- for placing ions base on potential All the Best. On Fri, Mar 14, 2014 at 1:43 PM, Andrew Bostick wrote: > Dear gromacs users > > In genion tool of gromacs, there are only Na and Cl ions. I want to add > Zn2+ ions to my system. > > How to add these ions with special concentration? > > Any help will highly appreciated > -- > Gromacs Users mailing list > > * Please search the archive at > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before > posting! > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > > * For (un)subscribe requests visit > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or > send a mail to gmx-users-requ...@gromacs.org. > -- Kalyan Reddy -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] genion
Dear gromacs users In genion tool of gromacs, there are only Na and Cl ions. I want to add Zn2+ ions to my system. How to add these ions with special concentration? Any help will highly appreciated -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] Dubious results with NPT
Hello, This time I tried sesiisotropic scaling with Berendsen Barostat. The compressibility was set to zero in Z-direction allowing scaling only in X and Y. The NPT simulation was run for 10ns. The result did not look good and the average pressure was ~36 bar (reference pressure is 1 bar). Even more confusing was the graphs of various properties against time. Pressure vs time shows a sudden decrease in fluctuations at about 5ns and thereafter . The pressure fluctuations lowered to around ~170bar from ~650 bar. A dramatic change was observed in many properties at around this time. For eg, the short range LJ interaction was found to decrease sharply at ~5ns. Also, total energy, Kinetic, Potential energies and the temperature showed a rapid drop in the magnitude of their fluctuations from the same time. Nothing notable was observed in the system trajectory at around this time. I am totally confused, and I feel that I made some very bad choice again the MDP file given below. Please let me know what you think. Suggest something on this issue which I should read about. ; 7.3.3 Run Control integrator = md tinit = 0 dt = 0.001 nsteps = 1000 comm_mode = Linear nstcomm = 1 comm_grps = CHX SOL ; 7.3.8 Output Control nstxout = 25000 nstvout = 25000 nstfout = 25000 nstlog = 100 nstenergy = 100 nstxtcout = 100 xtc_precision = 1000 xtc_grps = System energygrps = System ; 7.3.9 Neighbor Searching nstlist= 10 ns_type = grid pbc = xyz rlist = 0.9 ; 7.3.10 Electrostatics coulombtype = PME rcoulomb = 0.9 ; 7.3.11 VdW vdwtype = cut-off rvdw = 1.4 DispCorr = EnerPres ; 7.3.13 Ewald fourierspacing = 0.12 pme_order = 4 ewald_rtol= 1e-5 ; 7.3.14 Temperature Coupling tcoupl = nose-hoover tc_grps = CHXSOL tau_t = 0.50.5 ref_t = 298298 ; 7.3.15 Pressure Coupling pcoupl = berendsen pcoupltype = semiisotropic tau_p = 2.0 compressibility= 4.5e-5 0.0 ref_p = 1.01.0 ; 7.3.17 Velocity Generation gen_vel = no gen_temp= 298 gen_seed = -1 ; 7.3.18 Bonds constraints = none constraint_algorithm= LINCS continuation= no lincs_order = 4 lincs_iter = 1 lincs_warnangle = 30 Regards, Sujith. On Wed, Mar 12, 2014 at 5:28 PM, Justin Lemkul wrote: > > > On 3/12/14, 7:51 AM, sujithkakkat . wrote: > >> Hello, >> >> After a while I got back to the problem posted here. This issue was the >> large value for average pressure(~25 bar against the reference pressure >> of >> 1 bar) in NPT simulations with parrinello rahman barostat. The system >> studied is cyclohexane-water system with an interface. >> The forcefield is Gromos96. Gromacs 4.6.5 version is used. >> >> I recollect a post from Michael Shirts which says that with systems that >> are heterogeneous in direction (not uniform in x y and z), any errors in >> the pressure may be magnified. Is this what is happening in my case? >> >> Based on your suggestions , I tried the following to analyze/solve the >> problem, and till now the results have not improved a bit. >> >> (i) The system was simplified. Each phases was simulated separately. The >> results were good, with proper values of average pressure after NPT >> simulation for both independent water and cyclohexane systems. However, >> when doing the same with similar parameters on the water-cyclohexane >> combined system with parrinello-rahman barostat , still gives very high >> average pressure (even after 10ns ) >> >> (ii) Changing the tau_p values did not help either. (I tried 1ps, 2ps, >> and 4ps) >> >> My question is whether, I can try the semiisotropic scaling? The manual >> says that it is useful in case of systems with interface. I am not sure, >> since none of the replies I got suggested that option, which gives the >> impression that it is not the best solution. But , to my limited knowledge >> that is the only option left to be tried to solve the issue. >> >> > Worth a shot. Also try changing the barostat to Berendsen to see if that > changes anything. There are a lot of interrelated issues here, possibly a > problem with the barostat, the tau_p value, the type of coupling, the > combination of the integrator and barostat...you see how complicated it > gets, and that's only some of the possible issues. > > -Justin > > > >>The mdp
