Hi,
> I think it is clear that for example "disappearing" of some molecule X
> from the solvent brings solvent
> molecules from neighbourhood of X in closer distances as the space which
> was previously occupied by
> molecule X is now more and more free and hence "common"-"common"
> interaction (here solvent-solvent) changes here dramatically
> I think.
I am not sure what you mean, but aren't you thinking too complicated here?
What you describe certainly occurs in the simulation, but it is not part
of the derivative dVdl. Your complete potential energy function (including
*all* common/common, common/SC etc. interactions) can be written out as
V(lambda). It uses linear mixing for anything non-SC and you can therefore
write down the lambda-derivative of the total potential energy. Again, all
this is written out in our papers (hopefully) clearer than I can make it
here.
> So I see V(L) in two different contexts.
>
> 1) As the L-weighted interaction potential between "unique"-"common" atoms
> which has analytical formula
> and so also analytical formula for dV/dL.
>
> 2) As the total potential energy of the whole system which is composed of
> "unique"-"common", "common"-"common", but also
> "unique"-"unique" atom pairs interactions. Unfortunately for example
> the
> dependence of "common"-"common" part of the total potential
> energy on L is nontrivial and might to be pretty hard to express it
> analytically as well as it's derivation.
I think (1) has no specific meaning other than being part of your total
potential energy. (2) is what you want and its dependence on lambda is
indeed not hard to express analytically.
> From your response is it clear to me, that the values of dV/dL(L) are
> computed just with respect to the analytically
> well defined part ("unique"-"common" interacations) of the total
> potential energy in another words derivated V(L) has here meaning 1).
no, that is not the case in the actual code (and should not be)
> I will for sure check the relevant article and the code as you advised but
> for this
> moment I still do not see the necessity of two simultaneous sander runs in
> case on
> just one way TI processes (i.e. only charging or only uncharging or only
> vdw coupling or only vdw decoupling).
There is no necessity for two sander processes (even though it's
convenient) but you need to do two full energy/force calculations, one for
your start state, one for your end state. Since e.g. Ewald electrostatics
are not easily pairwise decomposable, changing even one partial charge
means you need to do the full calculation twice. Now if you have to call
energy() twice anyway, you might as well do it on two processes to improve
calculation speed.
> Here in principle just one PRMTOP should be enough if I am able to
> provide the rest information
> (definition of "unique" atoms and type of the TI change so to define V0
> and V1 state) as a part of *.in file. For this
> just one mask (like SCMASK) and another parameter which define one of the
> 4 possible TI changes
> should be enough. Is still mystery for me what the second sander thread is
> calculating in such one way cases
> but maybe after reading that article and checking that *.f file everything
> will be clear ( hopefully :)) ).
I believe that you could write a TI code that uses only one prmtop and
some extra info on the transformation, but I think it would not provide
any big benefit to the user.
Kind Regards,
Dr. Thomas Steinbrecher
formerly at the
BioMaps Institute
Rutgers University
610 Taylor Rd.
Piscataway, NJ 08854
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Dec 06 2011 - 02:00:02 PST
