[gmx-users] soft-core and coulomb transformation

[David Mobley]

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 viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >> _______________________________________________
> >> gmx-users mailing list    gmx-users at 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 gmx-users-request at gromacs.org.
> >> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
> >>
> > _______________________________________________
> > gmx-users mailing list    gmx-users at 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 gmx-users-request at gromacs.org.
> > 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 at 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 gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>