On Mon, 5 Nov 2007, David Mobley wrote:
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.
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.
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
#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
the change from opls_135 to opls_138 is silent, i.e., both have same
atomtype and same nonbonded parameters.
I hope i have explained the protocol in detail.
My 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.
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. 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.
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 list gmx-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 list gmx-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 list gmx-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
