[gmx-users] soft-core and coulomb transformation

bharat v. adkar bharat at sscu.iisc.ernet.in
Mon Nov 5 23:28:57 CET 2007 

On Mon, 5 Nov 2007, David Mobley wrote:

> 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.

yes. only for the charging component only.

>
> 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.
>
so i think, the topology is correct.

>> 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.
>

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.

>> 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?

> 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.

> 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
>

So, for my example, though SC is not essential for charge transformation, 
i use it and see the overley of dG/dlambda vs lambda for forward and 
reverse transformation (when plotted with the reverse scales on the same 
graph). This is because of *SOFT-CORE EFFECT*.

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.

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 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
>>
> _______________________________________________
> 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.

More information about the gromacs.org_gmx-users mailing list