Re: Setting up softcore parameters for FEP

From: Brian Radak (bradak_at_anl.gov)
Date: Thu Aug 03 2017 - 13:03:29 CDT

Aha, now I see your question. Yes, the two coupling schedules will
always overlap unless you completely deactivate one of the schedules.
Here is where I led you astray, the way to deactivate the schedule
rather contradicts the functional forms I gave you (which are not what
is used in the code).

So if you want *pure linear electrostatic decoupling*:

alchElecLambdaStart 0.0
alchVdwLambdaEnd 0.0 ;# vdw_couple is locked at 1 for all groups

or *pure vdw decoupling (possibly with soft-core)*:

alchElecLambdaStart 1.0 ;# elec_couple is locked at 0 for all groups
alchVdwLambdaEnd 1.0

I don't think things are as clear for mutations (is that what you are
doing?). Additional options might be needed to suit your purpose, but I
would think that overlapping schedules would make the most sense there.

Cheers,
Brian

On 08/03/2017 12:49 PM, John Green wrote:
> Thank you very much again. Still I think the example in user guide
> doesn't follow the above calculation since the calculation says
> decoupling is happening from 0.5 to 1 but in the picture (even
> considering we just have decoupling) decoupling happens at the first
> half.
>
> My question is regarding the overlap in electrostatic coupling and
> decoupling itself. Could we overlap or separate them (regardless of
> the LJ)? or we always have them at the same time?
>
> On Thu, Aug 3, 2017 at 12:02 PM, Brian Radak <bradak_at_anl.gov
> <mailto:bradak_at_anl.gov>> wrote:
>
> The conversions you show are correct - I'm not exactly sure what
> is confusing here (although the whole thing can be a bit
> confusing). I think the trouble is that the left hand plot in the
> user guide assumes that you only have one alchemical group (group
> -1 in that case) so that only "decoupling" is occurring.
>
> The real question is how much do you want electrostatic and van
> der Waal decoupling to overlap? Turning off the electrostatics
> completely before modifying vdW can be excessive and result in an
> inordinate number of alchLambda values. If you want to go that
> route, I'm not sure that you can run a single set of simulations
> since you would have to use "alchVdwLambdaEnd 0.0" for the first
> part and then change the value to 1.0 later.
>
> There has been some talk of updating some of these scheduling
> options, including adding decomposition of the vdW terms into
> attractive and repulsive components.
>
> Does that help?
>
> Brian
>
>
> On 08/03/2017 11:38 AM, John Green wrote:
>> Thank you very much. Let's focus on electrostatic coupling for a
>> moment. Let's say:
>> alchVdwLambdaEnd 1.0
>> alchElecLambdaStart 0.5
>>
>> So according to the formula you mentioned we have :
>>
>> elec_couple=max(0,2*lambda-1)
>> lambda=0 --> elec_couple=0 , elec_decouple=1
>> lambda=0.5 --> elec_couple=0 , elec_decouple=1
>> ambda=1 --> elec_couple=1 , elec_decouple=0
>>
>> So both decoupling and coupling happen between lambda (0.5 to 1).
>> But the left figure in this page shows that decoupling happens at
>> the first half (0 to 0.5)
>>
>> http://www.ks.uiuc.edu/Research/namd/2.10b1/ug/node61.html
>> <http://www.ks.uiuc.edu/Research/namd/2.10b1/ug/node61.html>
>>
>>
>> Did I miss something here?
>>
>>
>> Best,
>> JJ
>>
>> On Thu, Aug 3, 2017 at 8:20 AM, Brian Radak <bradak_at_anl.gov
>> <mailto:bradak_at_anl.gov>> wrote:
>>
>> Hi John,
>>
>> It is perfectly possible to overlap the regions or have them
>> be completely concurrent. For example, the following will
>> give you concurrent /linear/ coupling:
>>
>> alchVdwLambdaEnd 1.0
>> alchVdwShiftCoeff 0.0
>> alchElecLambdaStart 0.0
>>
>> I prefer to think of the coupling coefficients as functions
>> dependent on alchLambda:
>>
>> vdw_couple = min[1, alchLambda / alchVdwLambdaEnd]
>>
>> elec_couple = max[0, (alchLambda - alchElecLambdaStart) / (1
>> - alchElecLambdaStart)]
>>
>> The group 1 interactions are scaled by xxx_couple(alchLambda)
>> and the group -1 interactions are scaled by xxx_couple(1 -
>> alchLambda).
>>
>> New in NAMD2.12 (or maybe it was 2.11) there is now a
>> coupling for bonded terms that is completely analogous to vdW
>> coupling. This is off by default because alchBondLambdaEnd is
>> set to 0.0. You can also turn off vdW scaling with the same
>> trick or turn off elec scaling by setting alchElecLambdaStart
>> 1.0.
>>
>> HTH,
>> Brian
>>
>>
>> On 08/02/2017 04:18 PM, John Green wrote:
>>> Hi,
>>>
>>> I am trying to set up soft-core parameters for an FEP
>>> simulation. This is how this part of input file looks like:
>>>
>>> alchVdwLambdaEnd1.0
>>>
>>> alchElecLambdaStart 0.5
>>>
>>> alchVdWShiftCoeff5.0
>>>
>>> alchDecoupleno
>>>
>>>
>>> Based on tutorial, my understanding is that coupling and
>>> decoupling of electrostatic interaction for disappearing and
>>> appearing particles _always_ occur in two separate periods.
>>>
>>> [ 0 (1-alchElecLambdaStart) ] & [ (1-alchElecLambdaStart) 1 ]
>>>
>>>
>>> While for VDW you can have coupling and decoupling at the
>>> same time.
>>>
>>> [ (1-alchVdwLambdaEnd) 1 ] & [0 (1-alchVdwLambdaEnd) ]
>>>
>>> Is there any option to do that for electrostatic
>>> interactions as well? The manual says the default for
>>> alchElecLambdaStart is 0.5, so even if I don't use it in my
>>> script it wouldn't be helpful.
>>>
>>>
>>> Best,
>>>
>>> John
>>>
>>>
>>>
>>
>> --
>> Brian Radak
>> Postdoctoral Appointee
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>> 9700 South Cass Avenue, Bldg. 240
>> Argonne, IL 60439-4854
>> (630) 252-8643 <tel:%28630%29%20252-8643>
>> brian.radak_at_anl.gov <mailto:brian.radak_at_anl.gov>
>>
>>
>
> --
> Brian Radak
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
>
> 9700 South Cass Avenue, Bldg. 240
> Argonne, IL 60439-4854
> (630) 252-8643 <tel:%28630%29%20252-8643>
> brian.radak_at_anl.gov <mailto:brian.radak_at_anl.gov>
>
>

-- 
Brian Radak
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory
9700 South Cass Avenue, Bldg. 240
Argonne, IL 60439-4854
(630) 252-8643
brian.radak_at_anl.gov

This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:29 CST