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