Fwd: Sudden /\A drop in last FEP window

From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Sat Jul 28 2018 - 05:30:07 CDT

Hi Jerome:
By only changing alchVdWShiftCoeff from 4.0 to 6.0, your expectation was
fulfilled. The trend of /\A vs lambda was now smooth

....................
...................
0.9000/-12.4193
0.9100/-13.8066
0.9200/-15.0984
0.9300/-16.4011
0.9400/-17.5040
0.9500/-18.5221
0.9600/-19.5255
0.9700/-20.5133
0.9800/-21.4422
0.9900/-22.4359
1.0000/-23.6922

I cannot detect any alarming sign in the simulation, in particular, the
ligand remains undeformed and well in place throughout, not displaced, not
rotated.
Therefore, I am now perplexed at the value of /\A, differing by eight units
from previous FEP with alchVdWShiftCoeff = 4.0.
On the other hand, twenty windows for a small sector as 0.8-1.0 should not
be too few.

I would appreciate very much advice. Aas the change of alchVdWShiftCoeff
from 4.0 to 6.0 too large?

francesco

---------- Forwarded message ---------
From: Francesco Pietra <chiendarret_at_gmail.com>
Date: Fri, Jul 27, 2018 at 10:13 AM
Subject: Fwd: namd-l: Sudden /\A drop in last FEP window
To: <jerome.henin_at_ibpc.fr>, NAMD <namd-l_at_ks.uiuc.edu>

On these basis I have resubmitted (on the queue) that FEP from scratch, by
only changing alchVdWShiftCoeff from 4.0 to 6.0. We will see whether
further changes, as you suggested, are necessary

thanks

francesco

---------- Forwarded message ---------
From: Francesco Pietra <chiendarret_at_gmail.com>
Date: Thu, Jul 26, 2018 at 7:54 PM
Subject: Re: namd-l: Sudden /\A drop in last FEP window
To: <jerome.henin_at_ibpc.fr>
Cc: NAMD <namd-l_at_ks.uiuc.edu>

Hi Jerome
During my jogging I recognized to have missed the prot ocolin my mail. I
was too late, anyway the protocol follows:

outputenergies 1000
outputtiming 1000
outputpressure 1000
restartfreq 1000
XSTFreq 1000
dcdFreq 5000

hgroupcutoff 2.8
switching on
switchdist 10.0
cutoff 12.0
pairlistdist 14.0

wrapAll on

langevin on
langevintemp 300.0
langevindamping 2.0

langevinpiston on
langevinpistontarget 1
langevinpistonperiod 100
langevinpistondecay 100
langevinpistontemp 300
StrainRate 0.0 0.0 0.0
useGroupPressure yes

PME yes
PMETolerance 10e-6
PMEInterpOrder 4
PMEGridSpacing 1

timestep 0.5
fullelectfrequency 2
nonbondedfreq 1

rigidbonds water
stepspercycle 20

alch on
alchType FEP
alchFile npt-15_frwd.fep
alchCol B
alchOutFile frwd-08.fepout
alchOutFreq 50

alchVdwLambdaEnd 1.0
alchElecLambdaStart 0.5
alchVdWShiftCoeff 4.0
alchEquilSteps 100000
set numSteps 400000

runFEP 0.80 1.00 0.01 $numSteps

On Thu, Jul 26, 2018 at 6:48 PM Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:

> Hi,
>
> That is more or less an expected physical effect when the excluded volume
> due to LJ repulsion disappears. In principle the soft-core potentials were
> introduced to limit this effect (that is, to spread it over a broader range
> of lambda and remove the singularity). You can try experimenting with
> softer soft-core potentials by increasing the value of alchVdwShiftCoeff
> from its default of 5 Å^2. Just note that the risk with too much softening
> is to allow atoms of opposite charges to overlap, which leads to an
> electrostatic catastrophe (singular Coulomb energy). So the goal is to keep
> the barrier high enough that those clashes don't occur as long as the
> Coulomb potential is nonzero. If you are using a protocol that separates
> the contributions entirely, that is alchElecLambdaStart
> >= alchVdwLambdaEnd, then there is no such risk and I suppose anything goes.
>
> Jerome
>
> On Thu, 26 Jul 2018 at 17:46, Francesco Pietra <chiendarret_at_gmail.com>
> wrote:
>
>> Hello
>> With every ligand-receptor FEP that I am carrying out with NAMD2.12, I
>> noticed a sudden drop in the /\A values when when approaching lambda = 1.0,
>> which seems to me prone to introducing large errors. I understand what
>> happens in the system under such conditions, however i wonder whether the
>> trend is out of the norm because I am missing some control.
>>
>> For example, for a ligand-receptor FEP divided into five sectors (in
>> order to keep the calculations for each sector within 24hr), the
>> ParseFEP.log for the 0.8-1.0 sector (lambda 0.01, 20 windows) reports
>> lambda//\A
>> ......................
>> ....................
>> 0.9000/1.2495
>> 0.9100/1.2395
>> 0.9200/1.1549
>> 0.9300/1.0130
>> 0.9400/0.6102
>> 0.9500/-0.0087
>> 0.9600/-1.8900
>> 0.9700/-3.8335
>> 0.9800/-6.8530
>> 0.9900/-10.5326
>> 1.0000/-15.9730
>>
>> Thanks for advice
>> francesco pietra
>>
>

This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:21:19 CST