Re: [gmx-users] soft-core
Hi Well the tutorial in the following website has mentioned about the importance of sc_alpha and sc-power. Also the manual gives you more information. http://www.dillgroup.ucsf.edu/group/wiki/index.php/Free_Energy:_Tutorial. Regards Sai On Sun, Jun 13, 2010 at 6:56 PM, Justin A. Lemkul jalem...@vt.edu wrote: fancy2012 wrote: Dear GMX users, when I generate the input file of MD simulation using grompp, I get this error: ERROR: The soft-core power is 0 and can only be 1 or 2. I don't know how to figure it out? Could somebody give me a hand? Thanks very much in advance! You haven't specified a value for sc-power, so the default of zero is taken. Manual section 7.3.23. -Justin Here is the mdp file: cpp = /lib/cpp constraints = all-bonds integrator = md tinit = 0.0 dt = 0.002 nsteps = 25000 nstcomm = 1 nstxout = 1 nstvout = 0 nstfout = 0 nstlog = 500 nstenergy = 250 nstxtcout = 1000 xtc_precision = 1000 xtc_grps= Protein nstlist = 5 energygrps = Protein SOL ns_type = grid rlist = 0.9 coulombtype = Reaction-Field epsilon_r= 78.0 rcoulomb= 1.4 rvdw= 1.4 Tcoupl = Berendsen tc-grps = Protein SOL ref_t = 300 300 tau_t = 0.1 0.1 Pcoupl = Berendsen tau_p = 1.0 compressibility = 4.6e-5 ref_p;= 1.0 free_energy = yes init_lambda = 0.00 sc-alpha= 1.51 All the best, fancy -- Justin A. Lemkul Ph.D. Candidate ICTAS Doctoral Scholar MILES-IGERT Trainee Department of Biochemistry Virginia Tech Blacksburg, VA jalemkul[at]vt.edu | (540) 231-9080 http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php
[gmx-users] soft-core
Dear GMX users, when I generate the input file of MD simulation using grompp, I get this error: ERROR: The soft-core power is 0 and can only be 1 or 2. I don't know how to figure it out? Could somebody give me a hand? Thanks very much in advance! Here is the mdp file: cpp = /lib/cpp constraints = all-bonds integrator = md tinit = 0.0 dt = 0.002 nsteps = 25000 nstcomm = 1 nstxout = 1 nstvout = 0 nstfout = 0 nstlog = 500 nstenergy = 250 nstxtcout = 1000 xtc_precision = 1000 xtc_grps= Protein nstlist = 5 energygrps = Protein SOL ns_type = grid rlist = 0.9 coulombtype = Reaction-Field epsilon_r = 78.0 rcoulomb= 1.4 rvdw= 1.4 Tcoupl = Berendsen tc-grps = Protein SOL ref_t = 300 300 tau_t = 0.1 0.1 Pcoupl = Berendsen tau_p = 1.0 compressibility = 4.6e-5 ref_p = 1.0 free_energy = yes init_lambda = 0.00 sc-alpha= 1.51 All the best, fancy -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php
Re: [gmx-users] soft-core
fancy2012 wrote: Dear GMX users, when I generate the input file of MD simulation using grompp, I get this error: ERROR: The soft-core power is 0 and can only be 1 or 2. I don't know how to figure it out? Could somebody give me a hand? Thanks very much in advance! You haven't specified a value for sc-power, so the default of zero is taken. Manual section 7.3.23. -Justin Here is the mdp file: cpp = /lib/cpp constraints = all-bonds integrator = md tinit = 0.0 dt = 0.002 nsteps = 25000 nstcomm = 1 nstxout = 1 nstvout = 0 nstfout = 0 nstlog = 500 nstenergy = 250 nstxtcout = 1000 xtc_precision = 1000 xtc_grps= Protein nstlist = 5 energygrps = Protein SOL ns_type = grid rlist = 0.9 coulombtype = Reaction-Field epsilon_r= 78.0 rcoulomb= 1.4 rvdw= 1.4 Tcoupl = Berendsen tc-grps = Protein SOL ref_t = 300 300 tau_t = 0.1 0.1 Pcoupl = Berendsen tau_p = 1.0 compressibility = 4.6e-5 ref_p;= 1.0 free_energy = yes init_lambda = 0.00 sc-alpha= 1.51 All the best, fancy -- Justin A. Lemkul Ph.D. Candidate ICTAS Doctoral Scholar MILES-IGERT Trainee Department of Biochemistry Virginia Tech Blacksburg, VA jalemkul[at]vt.edu | (540) 231-9080 http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
Hi, The bug was indeed was I expected. I have fixed it for version 3.3.3. You might not notice it easily, since the direct space contribution is usually larger than the mesh part. But for a two particle system I got nan's. Berk. From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org To: Discussion list for GROMACS users gmx-users@gromacs.org Subject: Re: [gmx-users] soft-core and coulomb transformation Date: Mon, 12 Nov 2007 16:17:36 -0800 Berk, But what do you mean with charging and discharging? Going one way or the other in lambda does not matter. What matters is if there are particles that have zero charge in the A-state topology, while they have a non-zero charge in the B-state topology. Sorry, what I mean by charging versus discharging is that charging is where the A state has zero charges and the B state has normal charges, and discharging is the reverse. So charging is the scenario you describe, and discharging is the reverse. David Berk. From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org To: bharat v. adkar [EMAIL PROTECTED] CC: Discussion list for GROMACS users gmx-users@gromacs.org Subject: Re: [gmx-users] soft-core and coulomb transformation Date: Mon, 12 Nov 2007 10:26:37 -0800 Following up on this issue, discharging phenol in water appears to give the same results as charging phenol in water. In other words, so far the only cases for which there seem to be a problem are relative calculations (and so far I haven't looked at this for any other than Bharat's test cases). Bharat, be sure you submit a bugzilla and we'll see how things go from there. I may at some point try setting up some of my own relative free energy topologies and see if I see the same effects, but I'm not likely to have time for that for a couple days. Thanks, David _ Play online games with your friends with Messenger http://www.join.msn.com/messenger/overview ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php _ Live Search, for accurate results! http://www.live.nl ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
Hi, I can see the curves getting overlapped after the code-modification suggested by Berk for ethane to methane coulomb transformations in forward and reverse directions. Thanks Berk and David. bharat On Wed, 14 Nov 2007, bharat v. adkar wrote: hi, even i am also checking the ethane-methane case with the fix you suggested. equilibration values appear to be okay. will let you know by tommorrow the final results.. thanks bharat On Wed, 14 Nov 2007, Berk Hess wrote: Hi, The bug was indeed was I expected. I have fixed it for version 3.3.3. You might not notice it easily, since the direct space contribution is usually larger than the mesh part. But for a two particle system I got nan's. Berk. From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org To: Discussion list for GROMACS users gmx-users@gromacs.org Subject: Re: [gmx-users] soft-core and coulomb transformation Date: Mon, 12 Nov 2007 16:17:36 -0800 Berk, But what do you mean with charging and discharging? Going one way or the other in lambda does not matter. What matters is if there are particles that have zero charge in the A-state topology, while they have a non-zero charge in the B-state topology. Sorry, what I mean by charging versus discharging is that charging is where the A state has zero charges and the B state has normal charges, and discharging is the reverse. So charging is the scenario you describe, and discharging is the reverse. David Berk. From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org To: bharat v. adkar [EMAIL PROTECTED] CC: Discussion list for GROMACS users gmx-users@gromacs.org Subject: Re: [gmx-users] soft-core and coulomb transformation Date: Mon, 12 Nov 2007 10:26:37 -0800 Following up on this issue, discharging phenol in water appears to give the same results as charging phenol in water. In other words, so far the only cases for which there seem to be a problem are relative calculations (and so far I haven't looked at this for any other than Bharat's test cases). Bharat, be sure you submit a bugzilla and we'll see how things go from there. I may at some point try setting up some of my own relative free energy topologies and see if I see the same effects, but I'm not likely to have time for that for a couple days. Thanks, David _ Play online games with your friends with Messenger http://www.join.msn.com/messenger/overview ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php _ Live Search, for accurate results! http://www.live.nl ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
Hi, Bharat, and David vdS. This indeed is looking suspiciously like a real problem. FWIW, I did reproduce your original problem using my own input files and PME with gromacs 3.3.1. It's still a bit perplexing, in that you seem to be getting basically the right answers for the forward transformation (at least, by comparing the PME forward results with the cutoff forward results) but the reverse transformation is crazily wrong. I'm having a hard time figuring out what sort of bug could cause this to happen. The only thing I can come up with so far that might cause this is a bug in the handling of B state 1-4 interactions with PME. Since methane has no B state 1-4 electrostatic interactions, the ethane-methane transformation would be OK both with and without PME. But methane-ethane would go awry with PME because ethane still has 1-4 electrostatic interactions. If I remember correctly, though, you reported that the vacuum calculations work fine? That wouldn't be consistent with my explanation above, and perhaps would suggest that the problem is interactions with water, somehow? Just speculation at this point. I'm doing some more testing on this end (trying to come up with a more minimal example). I'm checking to see whether discharging phenol in water gives the same results as charging phenol in water. David On 11/11/07, bharat v. adkar [EMAIL PROTECTED] wrote: Hi David, I am keeping the subject same so that it is helpful to track in future :) On Sat, 10 Nov 2007, David Mobley wrote: Dear Bharat, OK, I went ahead and ran with your topologies using my own run scripts. My runs haven't finished yet, but looking at just dV/dlambda values from equilibration, I seem to be seeing roughly the same trends you do. In particular: (1) The forward simulation always gives dv/dlambda values that are fairly close to -2 at each lambda (2) The reverse simulation gives a range of dv/dlambda values at different lambda values, and switches from positive to negative as lambda increases. The integral of dV/dlambda in the forward case is NOT the negative of the integral of dV/dlambda for the reverse case, which is what it should be. Obviously, something is wrong here, and it doesn't seem to be your run input files. I don't see anything obviously wrong with your topology files, either -- as far as I can tell your charge groups are OK. My suggestion is to try to strip this down to a simpler case where it will become more clear what the problem is. Maybe ethane-methane rather than with the capping on the ends. (Did you say you have the same problem with ethane-methane? It would be easier to troubleshoot those topologies). As I mentioned earlier, ethane to methane transformation also shows the same behaviour. I am almost sure that the topologies and other input files are correct. I am pasting below the output of the coulomb-transformation for both, ethane to methane (forward) and methane to ethane (reverse). Topology is the same as i mentioned few mails back... Forward charge transformation lmbd dg/dlerror 0.00 -8.286304 0.0108319 0.05 -8.32708 0.0114018 0.10 -8.328157 0.0095819 0.15 -8.344236 0.00893341 0.25 -8.353463 0.00984712 0.40 -8.368163 0.0104302 0.50 -8.397035 0.00969758 0.60 -8.415603 0.00908416 0.75 -8.448185 0.00941215 0.85 -8.484247 0.00922024 0.90 -8.481465 0.00885981 0.95 -8.495802 0.00961897 1.00 -8.501283 0.00957299 Reverse charge transformation 0.00 13.770658 0.074592 0.05 13.331217 0.0778554 0.10 13.075527 0.0722786 0.15 12.483814 0.0750718 0.25 11.789282 0.0674654 0.40 10.730386 0.0875609 0.50 10.008684 0.0807128 0.60 9.266026 0.0736956 0.75 7.999017 0.0738001 0.85 7.388243 0.0832792 0.90 6.991334 0.0828869 0.95 6.595921 0.0796503 1.00 6.180366 0.0893983 As can be clearly seen, both transformations are not equivalent. (These are output from the 1 ns simulations.) If you get to the point where you're convinced it has nothing to do with your topology, you could submit a bugzilla -- but it would be a good idea to be more sure that there is no problem with your topology, first. Also it would be helpful to have more evidence about where the bug might be, if there is one (hence the importance of stripping this down to the minimum topology necessary to reproduce the problem). You might also, for example, just try turning off the charges on methane in water. You could also try turning on the charges in methane in water. These two should be equivalent (except for the sign) of course. Keep me posted on what you find out. to further see what happens, i used cut-off instead of pme and that seems to be giving okay results. i tried running only 20 ps runs as in equilibration, and there the values look as per expectations. then tried with Ace-Ala-Nac - Ace-Gly-Nac also. both seems okay. below are the values i obtained: Ethane - Methane forward 0.00 -8.277302
Re: [gmx-users] soft-core and coulomb transformation
Hi,
I am afraid you might be right.
I thought I had fixed all checks when implementing free energy for PME.
But it seems that the splines are only constructed for particles with
non-zero
A charges.
If this is the (only) problem, it can easily be checked by replacing
in pme.c in spread_on_grid both lines:
if (!bHaveSplines) {
by
if (TRUE) {
If this is the problem, I will fix it, but then (probably) still retaining
the optimization of using the B-splines only once.
I guess normally one would choose the B-state to be the zero state.
But for mutation studies this bug (if it is really the problem) could
give small errors that one might not notice directly...
Berk.
From: David Mobley [EMAIL PROTECTED]
Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org
To: bharat v. adkar [EMAIL PROTECTED]
CC: Discussion list for GROMACS users gmx-users@gromacs.org
Subject: Re: [gmx-users] soft-core and coulomb transformation
Date: Mon, 12 Nov 2007 08:45:33 -0800
Hi, Bharat, and David vdS.
This indeed is looking suspiciously like a real problem. FWIW, I did
reproduce your original problem using my own input files and PME with
gromacs 3.3.1.
It's still a bit perplexing, in that you seem to be getting basically
the right answers for the forward transformation (at least, by
comparing the PME forward results with the cutoff forward results) but
the reverse transformation is crazily wrong. I'm having a hard time
figuring out what sort of bug could cause this to happen.
The only thing I can come up with so far that might cause this is a
bug in the handling of B state 1-4 interactions with PME. Since
methane has no B state 1-4 electrostatic interactions, the
ethane-methane transformation would be OK both with and without PME.
But methane-ethane would go awry with PME because ethane still has
1-4 electrostatic interactions.
If I remember correctly, though, you reported that the vacuum
calculations work fine? That wouldn't be consistent with my
explanation above, and perhaps would suggest that the problem is
interactions with water, somehow?
Just speculation at this point.
I'm doing some more testing on this end (trying to come up with a more
minimal example). I'm checking to see whether discharging phenol in
water gives the same results as charging phenol in water.
David
On 11/11/07, bharat v. adkar [EMAIL PROTECTED] wrote:
Hi David,
I am keeping the subject same so that it is helpful to track in
future :)
On Sat, 10 Nov 2007, David Mobley wrote:
Dear Bharat,
OK, I went ahead and ran with your topologies using my own run
scripts. My runs haven't finished yet, but looking at just
dV/dlambda values from equilibration, I seem to be seeing roughly
the same trends you do. In particular:
(1) The forward simulation always gives dv/dlambda values that are
fairly close to -2 at each lambda
(2) The reverse simulation gives a range of dv/dlambda values at
different lambda values, and switches from positive to negative as
lambda increases.
The integral of dV/dlambda in the forward case is NOT the negative
of the integral of dV/dlambda for the reverse case, which is what it
should be.
Obviously, something is wrong here, and it doesn't seem to be your run
input files. I don't see anything obviously wrong with your topology
files, either -- as far as I can tell your charge groups are OK.
My suggestion is to try to strip this down to a simpler case where it
will become more clear what the problem is. Maybe ethane-methane
rather than with the capping on the ends. (Did you say you have the
same problem with ethane-methane? It would be easier to troubleshoot
those topologies).
As I mentioned earlier, ethane to methane transformation also shows the
same behaviour. I am almost sure that the topologies and other input
files are correct. I am pasting below the output of the
coulomb-transformation for both, ethane to methane (forward) and methane
to ethane (reverse). Topology is the same as i mentioned few mails
back...
Forward charge transformation
lmbd dg/dlerror
0.00 -8.286304 0.0108319
0.05 -8.32708 0.0114018
0.10 -8.328157 0.0095819
0.15 -8.344236 0.00893341
0.25 -8.353463 0.00984712
0.40 -8.368163 0.0104302
0.50 -8.397035 0.00969758
0.60 -8.415603 0.00908416
0.75 -8.448185 0.00941215
0.85 -8.484247 0.00922024
0.90 -8.481465 0.00885981
0.95 -8.495802 0.00961897
1.00 -8.501283 0.00957299
Reverse charge transformation
0.00 13.770658 0.074592
0.05 13.331217 0.0778554
0.10 13.075527 0.0722786
0.15 12.483814 0.0750718
0.25 11.789282 0.0674654
0.40 10.730386 0.0875609
0.50 10.008684 0.0807128
0.60 9.266026 0.0736956
0.75 7.999017 0.0738001
0.85 7.388243 0.0832792
0.90 6.991334 0.0828869
0.95 6.595921 0.0796503
1.00 6.180366 0.0893983
As can be clearly seen, both transformations are not equivalent. (These
are output from the 1 ns simulations.)
If you get to the point where you're convinced it has
Re: [gmx-users] soft-core and coulomb transformation
Following up on this issue, discharging phenol in water appears to give the same results as charging phenol in water. In other words, so far the only cases for which there seem to be a problem are relative calculations (and so far I haven't looked at this for any other than Bharat's test cases). Bharat, be sure you submit a bugzilla and we'll see how things go from there. I may at some point try setting up some of my own relative free energy topologies and see if I see the same effects, but I'm not likely to have time for that for a couple days. Thanks, David On 11/12/07, David Mobley [EMAIL PROTECTED] wrote: Hi, Bharat, and David vdS. This indeed is looking suspiciously like a real problem. FWIW, I did reproduce your original problem using my own input files and PME with gromacs 3.3.1. It's still a bit perplexing, in that you seem to be getting basically the right answers for the forward transformation (at least, by comparing the PME forward results with the cutoff forward results) but the reverse transformation is crazily wrong. I'm having a hard time figuring out what sort of bug could cause this to happen. The only thing I can come up with so far that might cause this is a bug in the handling of B state 1-4 interactions with PME. Since methane has no B state 1-4 electrostatic interactions, the ethane-methane transformation would be OK both with and without PME. But methane-ethane would go awry with PME because ethane still has 1-4 electrostatic interactions. If I remember correctly, though, you reported that the vacuum calculations work fine? That wouldn't be consistent with my explanation above, and perhaps would suggest that the problem is interactions with water, somehow? Just speculation at this point. I'm doing some more testing on this end (trying to come up with a more minimal example). I'm checking to see whether discharging phenol in water gives the same results as charging phenol in water. David On 11/11/07, bharat v. adkar [EMAIL PROTECTED] wrote: Hi David, I am keeping the subject same so that it is helpful to track in future :) On Sat, 10 Nov 2007, David Mobley wrote: Dear Bharat, OK, I went ahead and ran with your topologies using my own run scripts. My runs haven't finished yet, but looking at just dV/dlambda values from equilibration, I seem to be seeing roughly the same trends you do. In particular: (1) The forward simulation always gives dv/dlambda values that are fairly close to -2 at each lambda (2) The reverse simulation gives a range of dv/dlambda values at different lambda values, and switches from positive to negative as lambda increases. The integral of dV/dlambda in the forward case is NOT the negative of the integral of dV/dlambda for the reverse case, which is what it should be. Obviously, something is wrong here, and it doesn't seem to be your run input files. I don't see anything obviously wrong with your topology files, either -- as far as I can tell your charge groups are OK. My suggestion is to try to strip this down to a simpler case where it will become more clear what the problem is. Maybe ethane-methane rather than with the capping on the ends. (Did you say you have the same problem with ethane-methane? It would be easier to troubleshoot those topologies). As I mentioned earlier, ethane to methane transformation also shows the same behaviour. I am almost sure that the topologies and other input files are correct. I am pasting below the output of the coulomb-transformation for both, ethane to methane (forward) and methane to ethane (reverse). Topology is the same as i mentioned few mails back... Forward charge transformation lmbd dg/dlerror 0.00 -8.286304 0.0108319 0.05 -8.32708 0.0114018 0.10 -8.328157 0.0095819 0.15 -8.344236 0.00893341 0.25 -8.353463 0.00984712 0.40 -8.368163 0.0104302 0.50 -8.397035 0.00969758 0.60 -8.415603 0.00908416 0.75 -8.448185 0.00941215 0.85 -8.484247 0.00922024 0.90 -8.481465 0.00885981 0.95 -8.495802 0.00961897 1.00 -8.501283 0.00957299 Reverse charge transformation 0.00 13.770658 0.074592 0.05 13.331217 0.0778554 0.10 13.075527 0.0722786 0.15 12.483814 0.0750718 0.25 11.789282 0.0674654 0.40 10.730386 0.0875609 0.50 10.008684 0.0807128 0.60 9.266026 0.0736956 0.75 7.999017 0.0738001 0.85 7.388243 0.0832792 0.90 6.991334 0.0828869 0.95 6.595921 0.0796503 1.00 6.180366 0.0893983 As can be clearly seen, both transformations are not equivalent. (These are output from the 1 ns simulations.) If you get to the point where you're convinced it has nothing to do with your topology, you could submit a bugzilla -- but it would be a good idea to be more sure that there is no problem with your topology, first. Also it would be helpful to have more evidence about where the bug might be, if there is
Re: [gmx-users] soft-core and coulomb transformation
Hi, But what do you mean with charging and discharging? Going one way or the other in lambda does not matter. What matters is if there are particles that have zero charge in the A-state topology, while they have a non-zero charge in the B-state topology. Berk. From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org To: bharat v. adkar [EMAIL PROTECTED] CC: Discussion list for GROMACS users gmx-users@gromacs.org Subject: Re: [gmx-users] soft-core and coulomb transformation Date: Mon, 12 Nov 2007 10:26:37 -0800 Following up on this issue, discharging phenol in water appears to give the same results as charging phenol in water. In other words, so far the only cases for which there seem to be a problem are relative calculations (and so far I haven't looked at this for any other than Bharat's test cases). Bharat, be sure you submit a bugzilla and we'll see how things go from there. I may at some point try setting up some of my own relative free energy topologies and see if I see the same effects, but I'm not likely to have time for that for a couple days. Thanks, David _ Play online games with your friends with Messenger http://www.join.msn.com/messenger/overview ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
Berk, But what do you mean with charging and discharging? Going one way or the other in lambda does not matter. What matters is if there are particles that have zero charge in the A-state topology, while they have a non-zero charge in the B-state topology. Sorry, what I mean by charging versus discharging is that charging is where the A state has zero charges and the B state has normal charges, and discharging is the reverse. So charging is the scenario you describe, and discharging is the reverse. David Berk. From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users gmx-users@gromacs.org To: bharat v. adkar [EMAIL PROTECTED] CC: Discussion list for GROMACS users gmx-users@gromacs.org Subject: Re: [gmx-users] soft-core and coulomb transformation Date: Mon, 12 Nov 2007 10:26:37 -0800 Following up on this issue, discharging phenol in water appears to give the same results as charging phenol in water. In other words, so far the only cases for which there seem to be a problem are relative calculations (and so far I haven't looked at this for any other than Bharat's test cases). Bharat, be sure you submit a bugzilla and we'll see how things go from there. I may at some point try setting up some of my own relative free energy topologies and see if I see the same effects, but I'm not likely to have time for that for a couple days. Thanks, David _ Play online games with your friends with Messenger http://www.join.msn.com/messenger/overview ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
Hi David, I am keeping the subject same so that it is helpful to track in future :) On Sat, 10 Nov 2007, David Mobley wrote: Dear Bharat, OK, I went ahead and ran with your topologies using my own run scripts. My runs haven't finished yet, but looking at just dV/dlambda values from equilibration, I seem to be seeing roughly the same trends you do. In particular: (1) The forward simulation always gives dv/dlambda values that are fairly close to -2 at each lambda (2) The reverse simulation gives a range of dv/dlambda values at different lambda values, and switches from positive to negative as lambda increases. The integral of dV/dlambda in the forward case is NOT the negative of the integral of dV/dlambda for the reverse case, which is what it should be. Obviously, something is wrong here, and it doesn't seem to be your run input files. I don't see anything obviously wrong with your topology files, either -- as far as I can tell your charge groups are OK. My suggestion is to try to strip this down to a simpler case where it will become more clear what the problem is. Maybe ethane-methane rather than with the capping on the ends. (Did you say you have the same problem with ethane-methane? It would be easier to troubleshoot those topologies). As I mentioned earlier, ethane to methane transformation also shows the same behaviour. I am almost sure that the topologies and other input files are correct. I am pasting below the output of the coulomb-transformation for both, ethane to methane (forward) and methane to ethane (reverse). Topology is the same as i mentioned few mails back... Forward charge transformation lmbd dg/dlerror 0.00 -8.286304 0.0108319 0.05 -8.32708 0.0114018 0.10 -8.328157 0.0095819 0.15 -8.344236 0.00893341 0.25 -8.353463 0.00984712 0.40 -8.368163 0.0104302 0.50 -8.397035 0.00969758 0.60 -8.415603 0.00908416 0.75 -8.448185 0.00941215 0.85 -8.484247 0.00922024 0.90 -8.481465 0.00885981 0.95 -8.495802 0.00961897 1.00 -8.501283 0.00957299 Reverse charge transformation 0.00 13.770658 0.074592 0.05 13.331217 0.0778554 0.10 13.075527 0.0722786 0.15 12.483814 0.0750718 0.25 11.789282 0.0674654 0.40 10.730386 0.0875609 0.50 10.008684 0.0807128 0.60 9.266026 0.0736956 0.75 7.999017 0.0738001 0.85 7.388243 0.0832792 0.90 6.991334 0.0828869 0.95 6.595921 0.0796503 1.00 6.180366 0.0893983 As can be clearly seen, both transformations are not equivalent. (These are output from the 1 ns simulations.) If you get to the point where you're convinced it has nothing to do with your topology, you could submit a bugzilla -- but it would be a good idea to be more sure that there is no problem with your topology, first. Also it would be helpful to have more evidence about where the bug might be, if there is one (hence the importance of stripping this down to the minimum topology necessary to reproduce the problem). You might also, for example, just try turning off the charges on methane in water. You could also try turning on the charges in methane in water. These two should be equivalent (except for the sign) of course. Keep me posted on what you find out. to further see what happens, i used cut-off instead of pme and that seems to be giving okay results. i tried running only 20 ps runs as in equilibration, and there the values look as per expectations. then tried with Ace-Ala-Nac - Ace-Gly-Nac also. both seems okay. below are the values i obtained: Ethane - Methane forward 0.00 -8.277302 0.0747561 0.05 -8.346413 0.105338 0.10 -8.311737 0.0775508 0.15 -8.326182 0.0749244 0.25 -8.383022 0.0741275 0.40 -8.309543 0.199901 0.50 -8.388351 0.0807475 0.60 -8.334778 0.0769525 0.75 -8.444722 0.0556352 0.85 -8.541355 0.0529021 0.90 -8.562161 0.079475 0.95 -8.588182 0.0679287 1.00 -8.535591 0.0505447 reverse 0.00 8.647486 0.0848346 0.05 8.571583 0.067 0.10 8.410289 0.04688 0.15 8.336588 0.085721 0.25 8.536206 0.0457025 0.40 8.452587 0.0730119 0.50 8.397571 0.0540216 0.60 8.379067 0.0775835 0.75 8.345908 0.0889559 0.85 8.408099 0.082048 0.90 8.284268 0.0632315 0.95 8.1428 0.123793 1.00 8.303987 0.0505205 and for Ace-Ala-Nac - Ace-Gly-Nac forward 0.00 -2.113457 0.160573 0.05 -2.056746 0.0790143 0.10 -2.619748 0.242052 0.15 -2.470358 0.247365 0.25 -2.121426 0.623961 0.35 -2.210045 0.0567349 0.45 -2.173477 0.0483762 0.50 -2.156053 0.167631 0.55 -2.156565 0.0948302 0.65 -2.194102 0.0810602 0.75 -2.302156 0.306185 0.85 -2.28119 0.0545011 0.90 -1.936869 0.147152 0.95 -2.275215 0.190621 1.00 -2.221756 0.124669 reverse 0.00 2.30627 0.169452 0.05 2.102584 0.181941 0.10 2.531891 0.27292 0.15 2.491334 0.200524 0.25 2.020721 0.0577124 0.35 2.42911 0.133624 0.45 2.113785 0.24776 0.50 2.312891 0.056794 0.55 2.147666 0.0652882 0.65 2.259201 0.0969329 0.75 2.341642 0.0767809 0.85 2.381157 0.19062 0.90 2.29 0.238674 0.95 2.197692 0.175085 1.00 1.921228 0.0853432 in both the cases, the values do not change much, but they appear to be satisfying. So everythings
Re: [gmx-users] soft-core and coulomb transformation
bharat v. adkar wrote: Hi David, I am keeping the subject same so that it is helpful to track in future :) On Sat, 10 Nov 2007, David Mobley wrote: Dear Bharat, OK, I went ahead and ran with your topologies using my own run scripts. My runs haven't finished yet, but looking at just dV/dlambda values from equilibration, I seem to be seeing roughly the same trends you do. In particular: (1) The forward simulation always gives dv/dlambda values that are fairly close to -2 at each lambda (2) The reverse simulation gives a range of dv/dlambda values at different lambda values, and switches from positive to negative as lambda increases. The integral of dV/dlambda in the forward case is NOT the negative of the integral of dV/dlambda for the reverse case, which is what it should be. Obviously, something is wrong here, and it doesn't seem to be your run input files. I don't see anything obviously wrong with your topology files, either -- as far as I can tell your charge groups are OK. My suggestion is to try to strip this down to a simpler case where it will become more clear what the problem is. Maybe ethane-methane rather than with the capping on the ends. (Did you say you have the same problem with ethane-methane? It would be easier to troubleshoot those topologies). As I mentioned earlier, ethane to methane transformation also shows the same behaviour. I am almost sure that the topologies and other input files are correct. I am pasting below the output of the coulomb-transformation for both, ethane to methane (forward) and methane to ethane (reverse). Topology is the same as i mentioned few mails back... Forward charge transformation lmbd dg/dlerror 0.00 -8.286304 0.0108319 0.05 -8.32708 0.0114018 0.10 -8.328157 0.0095819 0.15 -8.344236 0.00893341 0.25 -8.353463 0.00984712 0.40 -8.368163 0.0104302 0.50 -8.397035 0.00969758 0.60 -8.415603 0.00908416 0.75 -8.448185 0.00941215 0.85 -8.484247 0.00922024 0.90 -8.481465 0.00885981 0.95 -8.495802 0.00961897 1.00 -8.501283 0.00957299 Reverse charge transformation 0.00 13.770658 0.074592 0.05 13.331217 0.0778554 0.10 13.075527 0.0722786 0.15 12.483814 0.0750718 0.25 11.789282 0.0674654 0.40 10.730386 0.0875609 0.50 10.008684 0.0807128 0.60 9.266026 0.0736956 0.75 7.999017 0.0738001 0.85 7.388243 0.0832792 0.90 6.991334 0.0828869 0.95 6.595921 0.0796503 1.00 6.180366 0.0893983 As can be clearly seen, both transformations are not equivalent. (These are output from the 1 ns simulations.) If you get to the point where you're convinced it has nothing to do with your topology, you could submit a bugzilla -- but it would be a good idea to be more sure that there is no problem with your topology, first. Also it would be helpful to have more evidence about where the bug might be, if there is one (hence the importance of stripping this down to the minimum topology necessary to reproduce the problem). You might also, for example, just try turning off the charges on methane in water. You could also try turning on the charges in methane in water. These two should be equivalent (except for the sign) of course. Keep me posted on what you find out. to further see what happens, i used cut-off instead of pme and that seems to be giving okay results. i tried running only 20 ps runs as in equilibration, and there the values look as per expectations. then tried with Ace-Ala-Nac - Ace-Gly-Nac also. both seems okay. below are the values i obtained: Ethane - Methane forward 0.00 -8.277302 0.0747561 0.05 -8.346413 0.105338 0.10 -8.311737 0.0775508 0.15 -8.326182 0.0749244 0.25 -8.383022 0.0741275 0.40 -8.309543 0.199901 0.50 -8.388351 0.0807475 0.60 -8.334778 0.0769525 0.75 -8.444722 0.0556352 0.85 -8.541355 0.0529021 0.90 -8.562161 0.079475 0.95 -8.588182 0.0679287 1.00 -8.535591 0.0505447 reverse 0.00 8.647486 0.0848346 0.05 8.571583 0.067 0.10 8.410289 0.04688 0.15 8.336588 0.085721 0.25 8.536206 0.0457025 0.40 8.452587 0.0730119 0.50 8.397571 0.0540216 0.60 8.379067 0.0775835 0.75 8.345908 0.0889559 0.85 8.408099 0.082048 0.90 8.284268 0.0632315 0.95 8.1428 0.123793 1.00 8.303987 0.0505205 and for Ace-Ala-Nac - Ace-Gly-Nac forward 0.00 -2.113457 0.160573 0.05 -2.056746 0.0790143 0.10 -2.619748 0.242052 0.15 -2.470358 0.247365 0.25 -2.121426 0.623961 0.35 -2.210045 0.0567349 0.45 -2.173477 0.0483762 0.50 -2.156053 0.167631 0.55 -2.156565 0.0948302 0.65 -2.194102 0.0810602 0.75 -2.302156 0.306185 0.85 -2.28119 0.0545011 0.90 -1.936869 0.147152 0.95 -2.275215 0.190621 1.00 -2.221756 0.124669 reverse 0.00 2.30627 0.169452 0.05 2.102584 0.181941 0.10 2.531891 0.27292 0.15 2.491334 0.200524 0.25 2.020721 0.0577124 0.35 2.42911 0.133624 0.45 2.113785 0.24776 0.50 2.312891 0.056794 0.55 2.147666 0.0652882 0.65 2.259201 0.0969329 0.75 2.341642 0.0767809 0.85 2.381157 0.19062 0.90 2.29 0.238674 0.95 2.197692 0.175085 1.00 1.921228 0.0853432 in both the cases, the values do not change much, but they appear to be
Re: [gmx-users] soft-core and coulomb transformation
Bharat,
Your values for the first set of calculations (the forward case?)
below look really weird. I suspect you have something messed up in
those runs. Have you checked that your define statements worked
properly, and checked your run input files? In particular, your
dv/dlambda is staying almost constant as a function of lambda, which
shouldn't be the case. Check the headers of your log files, perhaps,
and make sure lambda is set to what you think it should be, and make
sure your define statement for forward and reverse is really working
properly.
I'll do some more poking around myself.
Also, take a look at the charge groups in your topology file; I'm not
too up on how charge groups are supposed to be used, but I do remember
that when I usually set up proteins using pdb2gmx, I usually get
roughly one charge group per atom, and you have one charge group per
residue for a couple of your residues, but the middle residue is split
into three. Not sure how you decided to do that but it looks weird --
may want to look at the documentation here.
David
On Nov 9, 2007 11:27 PM, bharat v. adkar [EMAIL PROTECTED] wrote:
hi,
i am pasting the xmgrace file for the both forward and reverse
transformation of charge modification for Ala-Gly mutation.
The simulations are performed in water. when you open the file with
xmgrace, you can clearly see the behaviour what i was describing in
previous mails.
bharat
#
# Grace project file
#
@version 50120
@map color 11 to (255,0,0), red
@with g0
@world -0.05, -5.45, 1.05, 4.45
@view 0.15, 0.15, 1.15, 0.85
@title charge transformation
@subtitle without soft-core potentials
@xaxis on
@xaxis label \xl\f{}
@xaxis tick on
@xaxis tick major 0.2
@xaxis tick minor ticks 1
@xaxis ticklabel on
@yaxis on
@yaxis label dG/d\xl\f{} (kJ\#{b7}mol\S-1\N\#{b7}\xl\f{}\S-1\N)
@yaxis tick on
@yaxis tick major 1
@yaxis tick minor ticks 1
@yaxis ticklabel on
@legend on
@legend 0.5, 0.8
@legend box pattern 0
@s0 type xydy
@s0 errorbar on
@s0 comment FWD/coul_fwd_dgdl
@s0 legend fwd [(Ace-Ala-Nac) -- (Ace-Gly-Nac)]
@g1 on
@g1 hidden false
@g1 type XY
@g1 stacked false
@g1 bar hgap 0.00
@g1 fixedpoint off
@g1 fixedpoint type 0
@g1 fixedpoint xy 0.00, 0.00
@g1 fixedpoint format general general
@g1 fixedpoint prec 6, 6
@with g1
@world -0.05, -4.45, 1.05, 5.45
@view 0.15, 0.15, 1.15, 0.85
@xaxes invert on
@yaxes invert on
@xaxis on
@xaxis tick on
@xaxis tick major 0.2
@xaxis tick minor ticks 1
@xaxis ticklabel place opposite
@xaxis ticklabel color 11
@yaxis on
@yaxis tick on
@yaxis tick major 1
@yaxis tick minor ticks 1
@yaxis ticklabel place opposite
@yaxis ticklabel color 11
@legend on
@legend 0.5, 0.75
@legend box pattern 0
@s0 type xydy
@s0 line color 11
@s0 errorbar on
@s0 errorbar color 11
@s0 comment REV/coul_rev_dgdl
@s0 legend rev [(Ace-Gly-Nac) -- (Ace-Ala-Nac)]
@target G0.S0
@type xydy
0.00 -2.203320 0.055352
0.05 -2.299345 0.0520252
0.10 -2.358355 0.145189
0.15 -2.318708 0.108821
0.25 -2.506092 0.055204
0.35 -2.201419 0.0590116
0.45 -2.484940 0.0969871
0.50 -2.433880 0.0532859
0.55 -2.462887 0.0775993
0.65 -2.619397 0.0606133
0.75 -2.622916 0.0757515
0.85 -2.517759 0.0644187
0.90 -2.636431 0.0590214
0.95 -2.599439 0.10389
1.00 -2.563080 0.0581629
@target G1.S0
@type xydy
0.00 4.627166 0.0879965
0.05 4.118060 0.0790556
0.10 3.916284 0.0833586
0.15 3.588531 0.0804413
0.25 2.05 0.0928452
0.35 1.823581 0.0706488
0.45 1.047328 0.0957733
0.50 0.837857 0.0728831
0.55 0.529029 0.0765816
0.65 -0.281202 0.0716938
0.75 -0.995985 0.0706986
0.85 -1.947576 0.0761678
0.90 -2.328663 0.0707552
0.95 -2.589109 0.0834396
1.00 -3.052700 0.0640444
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
gmx-users mailing listgmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
___
gmx-users mailing listgmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
hi,
i am pasting the xmgrace file for the both forward and reverse
transformation of charge modification for Ala-Gly mutation.
The simulations are performed in water. when you open the file with
xmgrace, you can clearly see the behaviour what i was describing in
previous mails.
bharat
#
# Grace project file
#
@version 50120
@map color 11 to (255,0,0), red
@with g0
@world -0.05, -5.45, 1.05, 4.45
@view 0.15, 0.15, 1.15, 0.85
@title charge transformation
@subtitle without soft-core potentials
@xaxis on
@xaxis label \xl\f{}
@xaxis tick on
@xaxis tick major 0.2
@xaxis tick minor ticks 1
@xaxis ticklabel on
@yaxis on
@yaxis label dG/d\xl\f{} (kJ\#{b7}mol\S-1\N\#{b7}\xl\f{}\S-1\N)
@yaxis tick on
@yaxis tick major 1
@yaxis tick minor ticks 1
@yaxis ticklabel on
@legend on
@legend 0.5, 0.8
@legend box pattern 0
@s0 type xydy
@s0 errorbar on
@s0 comment FWD/coul_fwd_dgdl
@s0 legend fwd [(Ace-Ala-Nac) -- (Ace-Gly-Nac)]
@g1 on
@g1 hidden false
@g1 type XY
@g1 stacked false
@g1 bar hgap 0.00
@g1 fixedpoint off
@g1 fixedpoint type 0
@g1 fixedpoint xy 0.00, 0.00
@g1 fixedpoint format general general
@g1 fixedpoint prec 6, 6
@with g1
@world -0.05, -4.45, 1.05, 5.45
@view 0.15, 0.15, 1.15, 0.85
@xaxes invert on
@yaxes invert on
@xaxis on
@xaxis tick on
@xaxis tick major 0.2
@xaxis tick minor ticks 1
@xaxis ticklabel place opposite
@xaxis ticklabel color 11
@yaxis on
@yaxis tick on
@yaxis tick major 1
@yaxis tick minor ticks 1
@yaxis ticklabel place opposite
@yaxis ticklabel color 11
@legend on
@legend 0.5, 0.75
@legend box pattern 0
@s0 type xydy
@s0 line color 11
@s0 errorbar on
@s0 errorbar color 11
@s0 comment REV/coul_rev_dgdl
@s0 legend rev [(Ace-Gly-Nac) -- (Ace-Ala-Nac)]
@target G0.S0
@type xydy
0.00 -2.203320 0.055352
0.05 -2.299345 0.0520252
0.10 -2.358355 0.145189
0.15 -2.318708 0.108821
0.25 -2.506092 0.055204
0.35 -2.201419 0.0590116
0.45 -2.484940 0.0969871
0.50 -2.433880 0.0532859
0.55 -2.462887 0.0775993
0.65 -2.619397 0.0606133
0.75 -2.622916 0.0757515
0.85 -2.517759 0.0644187
0.90 -2.636431 0.0590214
0.95 -2.599439 0.10389
1.00 -2.563080 0.0581629
@target G1.S0
@type xydy
0.00 4.627166 0.0879965
0.05 4.118060 0.0790556
0.10 3.916284 0.0833586
0.15 3.588531 0.0804413
0.25 2.05 0.0928452
0.35 1.823581 0.0706488
0.45 1.047328 0.0957733
0.50 0.837857 0.0728831
0.55 0.529029 0.0765816
0.65 -0.281202 0.0716938
0.75 -0.995985 0.0706986
0.85 -1.947576 0.0761678
0.90 -2.328663 0.0707552
0.95 -2.589109 0.0834396
1.00 -3.052700 0.0640444
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
gmx-users mailing listgmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
On Mon, 5 Nov 2007, David Mobley wrote: Hi, i am extremely sorry here.. i am plotting dg/dl vs lambda of reverse transformation onto that of forward with both axes reversed. so i should expect overlap. this is consistent with whatever you are saying. i am sorry for negligence and confusion. And taking the negative? yes but when i use SC while coulomb transforamtion also, as in LJ transformation, the curves overlap. Now the question is why is it necessary to use SC during charge transformation to get overlap of the curves. It makes no sense at least to me. My experience has been that when you turn on soft core, you get a lambda-dependent shape of the dG/dlambda curve *regardless* of what transformation you're doing (i.e., even if you're doing NOTHING). i too see the dependence. I don't understand what do you mean by doing NOTHING. Do you mean that initial and final states are the same, so the net change is NOTHING? Yes, when making no change to a molecule, there's still a lambda dependence with soft core. I assume this has to do with details of the implementation. It's only the TOTAL free energy change that is zero. Since both of your transformations here are small, with soft core on, your curve shape will be dominated by that characteristic shape from soft core, and so it will *appear* that your curves overlap perfectly. i have no experience of large transformations, but, i think, even there also the characteristic shape would be observed. anyway, only difference potentials are contributing and non-bonded interactions, which are getting soft-cored, will be too many than bonded ones (if you perturb bonded-interactions also). May be i am wrong, as bonded interactions are much stronger than nonbonded which would cancel the nonbonded contributions. My point is just that if you're trying to see signal (lambda dependence that is not due to soft core) buried in noise (the characteristic soft core shape of the curve) the signal has to be significant. Now, the modified question: why is there no overlap of the graph in the absence of SC potentials for charge transformations (again when plotted on the reverse scales, both x and y)?? The overall mod(dG) is also not same for both the simulations. I am not sure whether it is because of undersampling.. i don't think so. I am clueless. What exactly do you mean by no overlap? i.e., if you compute the two DeltaG values, how different is DeltaG_forward from -DeltaG_reverse? How does the difference compare to your computed uncertainty? All I can tell you at this point is that, if you are doing enough sampling, you have everything set up properly, and there are no bugs, DeltaG_forward MUST be equal to -DeltaG_reverse (within error). The amount of help we can provide is directly related to how much information you give; when you just say they don't overlap, it's hard to do anything to help. You could try providing us with dG/dl values at each lambad, or even with your topologies and run scripts so I can reproduce what you're doing i have sent the files to you off-list.. plz have a look at. thanks bharat David bharat please help. bharat You need to provide more detail on your protocol. David i tried this for simple ala-gly and ethane-methane transformations. please give me some insight into the problem... bharat -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting!
Re: [gmx-users] soft-core and coulomb transformation
Hi, Everything goes fine till this point. Now, i do reverse transformations to check for hysteresis. For vdw transformations, i get almost perfect overlap of dG/dlambda vs lambda for forward and reverse transformations, but for coloumb transformations, if i don't use soft-core potentials, i don't get any overlap (i understand that getting overlap in forward and reverse transformations is not the accurate-enough measure of absence of hysteresis, but for smaller systems 5 ns at each lambda value should be sufficiently enough sampling). I am not sure what you mean by directions. Can you clarify your protocol? For example, the protocol used in my tutorial has no directionality. The only way I can think of you having directionality is if you are either: (a) Using slow growth where lambda is a function of time (b) Running your simulations consecutively, where the simulation at each lambda value begins from the endpoint of the simulation at the previous lambda value. Neither of those is what I would particularly recommend, since both introduce additional hysteresis. I'd instead recommend running independent equilibrium simulations at different lambda values, making sure you equilibrate long enough at each. Ny doubt is why should this happen? if there is no problem like singularities in potentials, why should not using sc-potentials make such a difference? To clarify, you want to NOT use soft core potentials for electrostatics, and use SC for the LJ transformation. You need to provide more detail on your protocol. David i tried this for simple ala-gly and ethane-methane transformations. please give me some insight into the problem... bharat -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core and coulomb transformation
Hi, it is fairly straight FORWARD.. forward is from state A to state B, and reverse is from state B to state A. Say for example, forward transformation is going from ethane to methane. in this step, i define three of the terminal hydrogen on say C2, with zero charges and C2 with charge of hydrogen in B state having their vdw terms unchanged. During forward transformation of coulombs, i modify these charges with 15 lambda values inclusive of 0 and 1. simulations at each lambda value are independent of each other, i.e., starts with the same starting structure. simulation protocol at each lambda value has energy minimization, 20 ps equilibration, and 5 ns production steps. similarly, reverse transformation means going from methane to ethane. The protocol you're giving here is just for the charging component, right? 15 lambda values will definitely be more than enough. If you aren't getting the same answers for going from methane to ethane, versus (the negative of) ethane to methane, it either means: (a) You aren't running long enough, or (b) You have a topology error Given that you're running 5 ns at each lambda value, I suspect (b). See below. i am pasting the part of topology used for charge transformation: #ifdef coul_fwd 1 opls_135 1 ETH CA1 1 -0.18 12.011 opls_138 -0.24 12.011 2 opls_140 1 ETH HA11 1 0.06 1.008 3 opls_140 1 ETH HA12 1 0.06 1.008 4 opls_140 1 ETH HA13 1 0.06 1.008 5 opls_135 1 ETH CA2 1 -0.18 12.011 opls_135 0.06 12.011 6 opls_140 1 ETH HA21 1 0.06 1.008 opls_140 0 1.008 7 opls_140 1 ETH HA22 1 0.06 1.008 opls_140 0 1.008 8 opls_140 1 ETH HA23 1 0.06 1.008 opls_140 0 1.008 #endif I'm not sure why you're changing the atom type on atom 1 at this stage. Looking at the parameter file this doens't change the LJ parameters so it should be OK, though. Anyway, this looks all right to me. #ifdef coul_rev 1 opls_138 1 ETH CA1 1 -0.24 12.011 opls_135 -0.18 12.011 2 opls_140 1 ETH HA11 1 0.06 1.008 3 opls_140 1 ETH HA12 1 0.06 1.008 4 opls_140 1 ETH HA13 1 0.06 1.008 5 opls_135 1 ETH CA2 1 0.06 12.011 opls_135 -0.18 12.011 6 opls_140 1 ETH HA21 1 0 1.008 opls_140 0.06 1.008 7 opls_140 1 ETH HA22 1 0 1.008 opls_140 0.06 1.008 8 opls_140 1 ETH HA23 1 0 1.008 opls_140 0.06 1.008 #endif This looks all right to me too. that is what i am doing. i am using SC for vdw (LJ) transformation and no SC for charge transformation. My observation is i do not get overlap of dG/dl vs lambda curves when i do forward and reverse transformation (i hope, my definitions of forward and reverse are clear by now) of charges. Forgive me if this is obvious and you've already accounted for it, but you would't expect to get the same dG/dlambda curves for these two transformations. In particular, the total DeltaG from the one transformation should be the negative of that from the other transformation, AND the directionality is different ( 1-lambda from one maps to lambda from the other). What you want to check is not that the curves are identical but that DeltaG_forward = -DeltaG_reverse. but when i use SC while coulomb transforamtion also, as in LJ transformation, the curves overlap. Now the question is why is it necessary to use SC during charge transformation to get overlap of the curves. It makes no sense at least to me. My experience has been that when you turn on soft core, you get a lambda-dependent shape of the dG/dlambda curve *regardless* of what transformation you're doing (i.e., even if you're doing NOTHING). Since both of your transformations here are small, with soft core on, your curve shape will be dominated by that characteristic shape from soft core, and so it will *appear* that your curves overlap perfectly. In case that wasn't clear, consider the following scenario: You obtain two dG/dlambda curves that are somewhat different from one another, with maximal amplitudes of something like 1 kcal/mol. Then you overlay on top of those two curves the function 50*sin(lambda), or similar. Now the two curves will appear basically the same, because you've overlaid some function with much larger magnitude on top of them. Anyway... Just make sure you're thinking about this properly. I don't see why you should expect the dG/dlambda curves to overlay perfectly on top of one another. I would expect to see that, at each lambda_i, dG_forward/dlambda(lambda_i) = -dG_reverse/dlambda(1-lambda_i), I think. That is, you need to take the negative of the curve, and map it to 1-lambda from the transformation in the other direction. Then you should see overlap (within your uncertainty). David please help. bharat You need to provide more detail on your protocol. David i tried this for simple ala-gly and ethane-methane transformations. please give me some insight into the problem... bharat -- This message has been scanned for
Re: [gmx-users] soft-core and coulomb transformation
Hi, i am extremely sorry here.. i am plotting dg/dl vs lambda of reverse transformation onto that of forward with both axes reversed. so i should expect overlap. this is consistent with whatever you are saying. i am sorry for negligence and confusion. And taking the negative? but when i use SC while coulomb transforamtion also, as in LJ transformation, the curves overlap. Now the question is why is it necessary to use SC during charge transformation to get overlap of the curves. It makes no sense at least to me. My experience has been that when you turn on soft core, you get a lambda-dependent shape of the dG/dlambda curve *regardless* of what transformation you're doing (i.e., even if you're doing NOTHING). i too see the dependence. I don't understand what do you mean by doing NOTHING. Do you mean that initial and final states are the same, so the net change is NOTHING? Yes, when making no change to a molecule, there's still a lambda dependence with soft core. I assume this has to do with details of the implementation. It's only the TOTAL free energy change that is zero. Since both of your transformations here are small, with soft core on, your curve shape will be dominated by that characteristic shape from soft core, and so it will *appear* that your curves overlap perfectly. i have no experience of large transformations, but, i think, even there also the characteristic shape would be observed. anyway, only difference potentials are contributing and non-bonded interactions, which are getting soft-cored, will be too many than bonded ones (if you perturb bonded-interactions also). May be i am wrong, as bonded interactions are much stronger than nonbonded which would cancel the nonbonded contributions. My point is just that if you're trying to see signal (lambda dependence that is not due to soft core) buried in noise (the characteristic soft core shape of the curve) the signal has to be significant. Now, the modified question: why is there no overlap of the graph in the absence of SC potentials for charge transformations (again when plotted on the reverse scales, both x and y)?? The overall mod(dG) is also not same for both the simulations. I am not sure whether it is because of undersampling.. i don't think so. I am clueless. What exactly do you mean by no overlap? i.e., if you compute the two DeltaG values, how different is DeltaG_forward from -DeltaG_reverse? How does the difference compare to your computed uncertainty? All I can tell you at this point is that, if you are doing enough sampling, you have everything set up properly, and there are no bugs, DeltaG_forward MUST be equal to -DeltaG_reverse (within error). The amount of help we can provide is directly related to how much information you give; when you just say they don't overlap, it's hard to do anything to help. You could try providing us with dG/dl values at each lambad, or even with your topologies and run scripts so I can reproduce what you're doing David bharat please help. bharat You need to provide more detail on your protocol. David i tried this for simple ala-gly and ethane-methane transformations. please give me some insight into the problem... bharat -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please
[gmx-users] soft-core and coulomb transformation
Dear all, i am trying some very basic transformations by thermodynamic integration to calculate free energy difference. By following mailing-list archive, i learned that it is efficient to do coulomb transformations and LJ transformations separately. i use David Mobley's tutorial values for soft-coring, i.e., sc-alpha=0.5, sc-power=1, sc-sigma=0.3. As per list, since charge transformations are not hard, we are at liberty to use soft-core potentials for coulombs and that is quite logical, and yes, without sc, there is no problem in coulomb transformation. Everything goes fine till this point. Now, i do reverse transformations to check for hysteresis. For vdw transformations, i get almost perfect overlap of dG/dlambda vs lambda for forward and reverse transformations, but for coloumb transformations, if i don't use soft-core potentials, i don't get any overlap (i understand that getting overlap in forward and reverse transformations is not the accurate-enough measure of absence of hysteresis, but for smaller systems 5 ns at each lambda value should be sufficiently enough sampling). Ny doubt is why should this happen? if there is no problem like singularities in potentials, why should not using sc-potentials make such a difference? i tried this for simple ala-gly and ethane-methane transformations. please give me some insight into the problem... bharat -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core potential in combination with PME (sorry, again)
David Mobley wrote: If I remember correctly, basically what the Anwar paper tries to achieve is separately smoothing the two. You could probably accomplish the same thing by allowing separate sc-alpha and sc-power for Coulomb and LJ interactions so they can be tuned separately. I would suggest to implement exactly that in the version 4. As David mentioned, there CAN occur problems with the differing parameters. In contrast to David, I experienced no general benefit in using different parameters for coulomb and vdw, what may be somehow my fault, or, more likely (maybe also less ;) ), depend on the system one perturbs. If you would change the code somehow, that the parameters can be modified independendly, I would also suggest to implement a sort of sigmoidal behaviour for the lambda change. We did that for the 3.3.1 code, so I could, at least, provide you with the basic code for that. Regards Maik Goette, Dipl. Biol. Max Planck Institute for Biophysical Chemistry Theoretical computational biophysics department Am Fassberg 11 37077 Goettingen Germany Tel. : ++49 551 201 2310 Fax : ++49 551 201 2302 Email : mgoette[at]mpi-bpc.mpg.de mgoette2[at]gwdg.de WWW : http://www.mpibpc.gwdg.de/groups/grubmueller/ ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core potential in combination with PME
Hi, Tanks for your elaboration on the subject. I've done a couple of free energy simulations myself, also on disappearing charged atoms, but so far I've not yet encountered any of the instability problems you mention here (though I did encounter instabilities at high lamda values, caused by the flying ice cube problem). Your problem could very well be related to the force field, since I'm using G53a6 and you're probably using OPLS. Maybe the extra hydrogens are causing your troubles? I recommend Langevin dynamics (sd) to avoid the flying ice cube and related nonergodicity problems. I'm using AMBER. Yes, there are extra hydrogens. Related? Not sure. I agree with you that the ideal soft-core parameters for decoupling LJ may not be so ideal for decoupling Coulomb, and that this can lead to convergence problems and wrong free energy results. In that case a separate decoupling of LJ and Coulomb forces in fact may be the best answer. Right. Btw, David, are you still interested in feedback on your free energy tutorial, or do you consider that project finished? I used it as a starting point for my simulations and may have some interesting remarks and/or suggestions. It's not done; I need to do a much more extensive one at some point. I just put it up as a crude starting point. But feel free to send me comments off list if you have anything to say in terms of clarifications of the current one: I will be expanding it eventually, but in the meantime I can fix errors in the existing one or clarify. David Greetings, Jeroen Date: Fri, 13 Apr 2007 09:18:21 -0700 From: David Mobley [EMAIL PROTECTED] Subject: Re: [gmx-users] soft-core potential in combination with PME (sorry, again) To: Discussion list for GROMACS users gmx-users@gromacs.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Berk and all, I don't understand what David Mobley meant exactly. There is no Coulomb singularity with soft-core. Maybe one could have an unfortunate situation where the LJ is already very soft, but the Coulomb not very soft, which could lead to instabilities. But I have never encountered this. Anytime I do a simulation where I turn of both coulomb and LJ interactions at the same time, I run into this problem. Sometimes it's worse than others. Maybe it's because the 1/r^12 and 1/r have different r-dependencies? I don't know. I suspect the issue partly is just what's optimal: The soft core parameters that would be optimal for modifying Coulomb interactions are not optimal for modifying LJ interactions, and vise versa. So if you use soft core settings that give you a smooth transformation for LJ interactions, you do too much or too little smoothing of the Coulomb interactions and introduce large Coulombic forces. On the other hand, if you pick soft core parameters that are good for Coulomb interactions, you end up with large LJ forces. (For example, Coulomb transformations are nearly optimal with LINEAR lambda scaling (sc-alpha=0), but that doesn't work *at all* for LJ transformations. If I remember correctly, basically what the Anwar paper tries to achieve is separately smoothing the two. You could probably accomplish the same thing by allowing separate sc-alpha and sc-power for Coulomb and LJ interactions so they can be tuned separately. So, while formally using soft core for Coulomb removes the singularity, in practice I think the forces are still large enough (when using soft core parameters are tuned for LJ interactions) that instabilities result (at least for the stuff I do, with the force field I use). Hence my recommendation to do two stages. Anecdotally, I should mention that a bunch of different people have e-mailed asking me about various problems they're having where they get unexpected free energies, etc. I suggest they do the Coulombic and LJ parts separately, and invariably they write back that it works much better. David ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php ___ gmx-users mailing listgmx-users@gromacs.org http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] soft-core potential in combination with PME (sorry, again)
Berk and all, I don't understand what David Mobley meant exactly. There is no Coulomb singularity with soft-core. Maybe one could have an unfortunate situation where the LJ is already very soft, but the Coulomb not very soft, which could lead to instabilities. But I have never encountered this. Anytime I do a simulation where I turn of both coulomb and LJ interactions at the same time, I run into this problem. Sometimes it's worse than others. Maybe it's because the 1/r^12 and 1/r have different r-dependencies? I don't know. I suspect the issue partly is just what's optimal: The soft core parameters that would be optimal for modifying Coulomb interactions are not optimal for modifying LJ interactions, and vise versa. So if you use soft core settings that give you a smooth transformation for LJ interactions, you do too much or too little smoothing of the Coulomb interactions and introduce large Coulombic forces. On the other hand, if you pick soft core parameters that are good for Coulomb interactions, you end up with large LJ forces. (For example, Coulomb transformations are nearly optimal with LINEAR lambda scaling (sc-alpha=0), but that doesn't work *at all* for LJ transformations. If I remember correctly, basically what the Anwar paper tries to achieve is separately smoothing the two. You could probably accomplish the same thing by allowing separate sc-alpha and sc-power for Coulomb and LJ interactions so they can be tuned separately. So, while formally using soft core for Coulomb removes the singularity, in practice I think the forces are still large enough (when using soft core parameters are tuned for LJ interactions) that instabilities result (at least for the stuff I do, with the force field I use). Hence my recommendation to do two stages. Anecdotally, I should mention that a bunch of different people have e-mailed asking me about various problems they're having where they get unexpected free energies, etc. I suggest they do the Coulombic and LJ parts separately, and invariably they write back that it works much better. David Berk. From: Jeroen van Bemmelen [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Thu, 12 Apr 2007 12:38:56 +0200 Hi Berk (and others), Thanks a lot for your quick answer. And sorry to bother you again with this long email, but I still feel I'm missing something really essential here. I agree that in essence the convergence and the singularity are two different problems. And if I understand you correctly, my first conclusion (that it's completely fine to use soft-core together with PME, that it takes care of the singularity problem, both for the VDW and the electrostatic part at the same time, and that it does not lead to additional problems) was right. So numerical instabilities (simulation crash) during free energy calculations resulting from singularities (overlapping atoms) should not be an issue with ANY type of electrostatics method in GROMACS (even PME), just as long as you use the soft-core potential. But in that case I really don't understand why Anwar claims in his aforementioned paper that the electrostatics singularity problem is only solved by the standard soft-core potential for the simple truncation and reaction field schemes, and not for PME. And why David Mobley mentions numerical instabilities caused by charge-charge overlap (e.g. in http://www.gromacs.org/pipermail/gmx-users/2006- March/020785.html and other mails) while using soft-core. Are the mentioned numerical instabilities (simulation blowing up) resulting from charge overlap not a direct consequence of the singularity at r=0? And is the soft-core potential not supposed to take care of exactly THIS problem, by effectively limiting the forces as r--0? At least that's how I understand it from the Beutler paper and from the manual. So I guess somebody is wrong here, most likely I myself, and I hope you or someone else can clarify this a bit further. Thanks, Jeroen On Thu, 12 Apr 2007 09:19:56, Berk Hess wrote: Soft-core interactions are fully supported with PME. Both mails you quote do not state otherwise. The second mail refers to convergence issues when switching off LJ as well as electrostatics interactions. This problem will (probably) always be present, and has nothing to do with the singularities in the potentials, but with the fact that one often has awkward free energy landscapes at intermediate states. Berk. From: Jeroen van Bemmelen [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Thu, 12 Apr 2007 01:44:41 +0200 Hi all, After reading several posts on this subject on the mailing list, I'm still a bit confused. In http://www.gromacs.org
Re: [gmx-users] soft-core potential in combination with PME (sorry, again)
From: David Mobley [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: Discussion list for GROMACS users [EMAIL PROTECTED] Subject: Re: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Fri, 13 Apr 2007 09:18:21 -0700 Berk and all, I don't understand what David Mobley meant exactly. There is no Coulomb singularity with soft-core. Maybe one could have an unfortunate situation where the LJ is already very soft, but the Coulomb not very soft, which could lead to instabilities. But I have never encountered this. Anytime I do a simulation where I turn of both coulomb and LJ interactions at the same time, I run into this problem. Sometimes it's worse than others. Maybe it's because the 1/r^12 and 1/r have different r-dependencies? I don't know. I suspect the issue partly is just what's optimal: The soft core parameters that would be optimal for modifying Coulomb interactions are not optimal for modifying LJ interactions, and vise versa. So if you use soft core settings that give you a smooth transformation for LJ interactions, you do too much or too little smoothing of the Coulomb interactions and introduce large Coulombic forces. On the other hand, if you pick soft core parameters that are good for Coulomb interactions, you end up with large LJ forces. (For example, Coulomb transformations are nearly optimal with LINEAR lambda scaling (sc-alpha=0), but that doesn't work *at all* for LJ transformations. If I remember correctly, basically what the Anwar paper tries to achieve is separately smoothing the two. You could probably accomplish the same thing by allowing separate sc-alpha and sc-power for Coulomb and LJ interactions so they can be tuned separately. So, while formally using soft core for Coulomb removes the singularity, in practice I think the forces are still large enough (when using soft core parameters are tuned for LJ interactions) that instabilities result (at least for the stuff I do, with the force field I use). Hence my recommendation to do two stages. Anecdotally, I should mention that a bunch of different people have e-mailed asking me about various problems they're having where they get unexpected free energies, etc. I suggest they do the Coulombic and LJ parts separately, and invariably they write back that it works much better. David I agree that doing it separately is more efficient and causes less trouble. That would also be my advice. I can only say that I have never encountered instabilities, although I have had systems where I needed a lot of sampling because of inconvenient Coulomb vs LJ soft-core paths. I have not read Anwar's paper, but I think it would be impossible to devise a different Coulomb and LJ scaling that would solve the problem, as you also have to deal with neighboring atoms. The main problem is usually in hydrogen bonds involving hydrogens bound to other atoms. Berk. _ Live Search, for accurate results! http://www.live.nl ___ gmx-users mailing list[EMAIL PROTECTED] http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
RE: [gmx-users] soft-core potential in combination with PME (sorry, again)
Soft-core interactions are fully supported with PME. Both mails you quote do not state otherwise. The second mail refers to convergence issues when switching off LJ as well as electrostatics interactions. This problem will (probably) always be present, and has nothing to do with the singularities in the potentials, but with the fact that one often has awkward free energy landscapes at intermediate states. Berk. From: Jeroen van Bemmelen [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Thu, 12 Apr 2007 01:44:41 +0200 Hi all, After reading several posts on this subject on the mailing list, I'm still a bit confused. In http://www.gromacs.org/pipermail/gmx-users/2005- October/017691.html it is more or less suggested that the implementation of the soft-core potential for free energy calculations in combination with PME is relatively straightforward, and is comparable to its implementation when using other treatments of long range electrostatics. In addition, the GROMACS manual does not mention any differences or problems when using this combination. So from this I cautiously conclude that it's fine to use soft-core together with PME, that it takes care of the singularity problem (as soft-core should), and that it does not lead to additional problems (at least not compared to its use with other electrostatic treatments). However, from several discussions on this mailing list (e.g. http://www.gromacs.org/pipermail/gmx-users/2006-June/022388.html) I understand there are indeed problems when using this combination of parameters. Not only could it lead to convergence problems (which could be prevented by using a 3-stage strategy), but it could also lead to stability problems because of the singularity at r=0 (for which the soft-core potential was invented in the first place). Moreover, reference was made to an article by Anwar (J. Chem. Phys., 122, 224117 (2005)), according to which soft-core in combination with PME is still a no-go (unless you use Anwars method, which is significantly different from the standard GROMACS soft-core implementation). So from this I conclude that the soft-core potential for PME has NOT been implemented into GROMACS yet, or at least not in a way that solves the singularity problem sufficiently, which is contradicting my earlier conclusion. Obviously, I'm missing or misinterpreting something here. But could someone please clear up this subject for me? Thanks, Jeroen ___ gmx-users mailing list[EMAIL PROTECTED] http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php _ Play online games with your friends with Messenger http://www.join.msn.com/messenger/overview ___ gmx-users mailing list[EMAIL PROTECTED] http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php
RE: [gmx-users] soft-core potential in combination with PME (sorry, again)
Hi Berk (and others), Thanks a lot for your quick answer. And sorry to bother you again with this long email, but I still feel I'm missing something really essential here. I agree that in essence the convergence and the singularity are two different problems. And if I understand you correctly, my first conclusion (that it's completely fine to use soft-core together with PME, that it takes care of the singularity problem, both for the VDW and the electrostatic part at the same time, and that it does not lead to additional problems) was right. So numerical instabilities (simulation crash) during free energy calculations resulting from singularities (overlapping atoms) should not be an issue with ANY type of electrostatics method in GROMACS (even PME), just as long as you use the soft-core potential. But in that case I really don't understand why Anwar claims in his aforementioned paper that the electrostatics singularity problem is only solved by the standard soft-core potential for the simple truncation and reaction field schemes, and not for PME. And why David Mobley mentions numerical instabilities caused by charge-charge overlap (e.g. in http://www.gromacs.org/pipermail/gmx-users/2006- March/020785.html and other mails) while using soft-core. Are the mentioned numerical instabilities (simulation blowing up) resulting from charge overlap not a direct consequence of the singularity at r=0? And is the soft-core potential not supposed to take care of exactly THIS problem, by effectively limiting the forces as r--0? At least that's how I understand it from the Beutler paper and from the manual. So I guess somebody is wrong here, most likely I myself, and I hope you or someone else can clarify this a bit further. Thanks, Jeroen On Thu, 12 Apr 2007 09:19:56, Berk Hess wrote: Soft-core interactions are fully supported with PME. Both mails you quote do not state otherwise. The second mail refers to convergence issues when switching off LJ as well as electrostatics interactions. This problem will (probably) always be present, and has nothing to do with the singularities in the potentials, but with the fact that one often has awkward free energy landscapes at intermediate states. Berk. From: Jeroen van Bemmelen [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Thu, 12 Apr 2007 01:44:41 +0200 Hi all, After reading several posts on this subject on the mailing list, I'm still a bit confused. In http://www.gromacs.org/pipermail/gmx-users/2005- October/017691.html it is more or less suggested that the implementation of the soft-core potential for free energy calculations in combination with PME is relatively straightforward, and is comparable to its implementation when using other treatments of long range electrostatics. In addition, the GROMACS manual does not mention any differences or problems when using this combination. So from this I cautiously conclude that it's fine to use soft-core together with PME, that it takes care of the singularity problem (as soft-core should), and that it does not lead to additional problems (at least not compared to its use with other electrostatic treatments). However, from several discussions on this mailing list (e.g. http://www.gromacs.org/pipermail/gmx-users/2006-June/022388.html) I understand there are indeed problems when using this combination of parameters. Not only could it lead to convergence problems (which could be prevented by using a 3-stage strategy), but it could also lead to stability problems because of the singularity at r=0 (for which the soft-core potential was invented in the first place). Moreover, reference was made to an article by Anwar (J. Chem. Phys., 122, 224117 (2005)), according to which soft-core in combination with PME is still a no-go (unless you use Anwars method, which is significantly different from the standard GROMACS soft-core implementation). So from this I conclude that the soft-core potential for PME has NOT been implemented into GROMACS yet, or at least not in a way that solves the singularity problem sufficiently, which is contradicting my earlier conclusion. Obviously, I'm missing or misinterpreting something here. But could someone please clear up this subject for me? Thanks, Jeroen ___ gmx-users mailing list[EMAIL PROTECTED] http://www.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [EMAIL PROTECTED] Can't post? Read http://www.gromacs.org/mailing_lists/users.php _ Play online games with your friends with Messenger http
RE: [gmx-users] soft-core potential in combination with PME (sorry, again)
I don't know about Anwars paper. But I can say that their is no fundamental difference between PME and RF with soft-core. With the GROMACS setup they converge to exactly the same energies at any lambda value when you increase the RF cut-off. I don't understand what David Mobley meant exactly. There is no Coulomb singularity with soft-core. Maybe one could have an unfortunate situation where the LJ is already very soft, but the Coulomb not very soft, which could lead to instabilities. But I have never encountered this. Berk. From: Jeroen van Bemmelen [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Thu, 12 Apr 2007 12:38:56 +0200 Hi Berk (and others), Thanks a lot for your quick answer. And sorry to bother you again with this long email, but I still feel I'm missing something really essential here. I agree that in essence the convergence and the singularity are two different problems. And if I understand you correctly, my first conclusion (that it's completely fine to use soft-core together with PME, that it takes care of the singularity problem, both for the VDW and the electrostatic part at the same time, and that it does not lead to additional problems) was right. So numerical instabilities (simulation crash) during free energy calculations resulting from singularities (overlapping atoms) should not be an issue with ANY type of electrostatics method in GROMACS (even PME), just as long as you use the soft-core potential. But in that case I really don't understand why Anwar claims in his aforementioned paper that the electrostatics singularity problem is only solved by the standard soft-core potential for the simple truncation and reaction field schemes, and not for PME. And why David Mobley mentions numerical instabilities caused by charge-charge overlap (e.g. in http://www.gromacs.org/pipermail/gmx-users/2006- March/020785.html and other mails) while using soft-core. Are the mentioned numerical instabilities (simulation blowing up) resulting from charge overlap not a direct consequence of the singularity at r=0? And is the soft-core potential not supposed to take care of exactly THIS problem, by effectively limiting the forces as r--0? At least that's how I understand it from the Beutler paper and from the manual. So I guess somebody is wrong here, most likely I myself, and I hope you or someone else can clarify this a bit further. Thanks, Jeroen On Thu, 12 Apr 2007 09:19:56, Berk Hess wrote: Soft-core interactions are fully supported with PME. Both mails you quote do not state otherwise. The second mail refers to convergence issues when switching off LJ as well as electrostatics interactions. This problem will (probably) always be present, and has nothing to do with the singularities in the potentials, but with the fact that one often has awkward free energy landscapes at intermediate states. Berk. From: Jeroen van Bemmelen [EMAIL PROTECTED] Reply-To: Discussion list for GROMACS users [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [gmx-users] soft-core potential in combination with PME (sorry,again) Date: Thu, 12 Apr 2007 01:44:41 +0200 Hi all, After reading several posts on this subject on the mailing list, I'm still a bit confused. In http://www.gromacs.org/pipermail/gmx-users/2005- October/017691.html it is more or less suggested that the implementation of the soft-core potential for free energy calculations in combination with PME is relatively straightforward, and is comparable to its implementation when using other treatments of long range electrostatics. In addition, the GROMACS manual does not mention any differences or problems when using this combination. So from this I cautiously conclude that it's fine to use soft-core together with PME, that it takes care of the singularity problem (as soft-core should), and that it does not lead to additional problems (at least not compared to its use with other electrostatic treatments). However, from several discussions on this mailing list (e.g. http://www.gromacs.org/pipermail/gmx-users/2006-June/022388.html) I understand there are indeed problems when using this combination of parameters. Not only could it lead to convergence problems (which could be prevented by using a 3-stage strategy), but it could also lead to stability problems because of the singularity at r=0 (for which the soft-core potential was invented in the first place). Moreover, reference was made to an article by Anwar (J. Chem. Phys., 122, 224117 (2005)), according to which soft-core in combination with PME is still a no-go (unless you use Anwars method, which is significantly different from the standard GROMACS soft-core implementation). So from this I conclude that the soft-core potential for PME has NOT been implemented into GROMACS yet, or at least not in a way
