Re: vmd-l: Re: Re: Bug with FEP?

From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Tue Apr 17 2018 - 00:05:38 CDT

Thanks again. I'll try, as you suggest, by breaking FEP into two stages at
different lambda 0.05/0.1, while increasing preequil/FEP by tenfold.

I understand that experts trying to help users can get frustrated from
repeated problems or unattended suggestions. However, it should also be
understood that people come to FEP as one of the various tools to
understand their biological problem. In my case, it is the repeated failure
to get a diffraction analysis of the ligand-protein complex that brought me
to FEP. With no interest in FEP per se. A lot about practical use for real
problems that we have learned along these threads are not mentioned in the
tutorials, worse they are hidden under the warning that "this is advanced
material"

cheers
francesco

On Mon, Apr 16, 2018 at 6:31 PM, Brian Radak <brian.radak_at_gmail.com> wrote:

> On Sun, Apr 15, 2018 at 3:48 AM, Francesco Pietra <chiendarret_at_gmail.com>
> wrote:
>
>> Hi Brian
>>
>>> It looks like you are writing a restart file every 500 steps, which is
>>> incredibly frequent and stresses both NAMD performance and the disk. Even
>>> writing energies to output that frequently can measurably slow down a
>>> simulation.
>>>
>>
>> That (albeit values suggested in the tutorial) will be implemented into
>> next FEPs. Thanks.
>>
>> The problem remains that, with 400 windows, FEP for the Unbound has not
>> enough improved (unless I am pessimistic, please read below). I have
>> carried out ParseFEP with GC zero and either BAR or SOS. In both cases,
>> overlap (Probability sheets) is only satisfactory for the first and last
>> (25) sheet. In the first sheet, the red line (back) is much broader that
>> the black line (frwd). In the last sheet, just the contrary.
>>
>>
> I *really* don't think you are going to get useful results with 400
> windows - that defies all of my experience (which, albeit, is not primarily
> with ligand binding). This sounds like your simulations are simply not long
> enough and the mismatch is due to hysteresis.
>
>
>> On a global analysis, both Probability and Energy improved marginally
>> from 50 to 100 windows, and sensibly from 100 to 400 windows. With the last
>> free energy sheet of the latter, /\G (red-black) ranges from 0.1 in the
>> first ten windows, to 1.0 kcal/mol in the last few windows.
>>
>> From all that, it is clear that exploring the phase space with this
>> ligand (a good parameterization notwithstanding) is far from easy. Most
>> unfortunately, ParseFEP only assumes constant lambda and it is difficult to
>> circumvent it. I could consider to run FEP on 800 windows, however one may
>> wonder whether this can be a route to solve the ligand-protein problem. All
>> that in striking contrast with the reported easy FEP determinations for
>> protein-organic ligands that I already referred too (Chem. Sci., 2016, 7,
>> 207). The difference might rest on the "easier" (more rigid) ligands in
>> this ChemSci publications, although it still strikes me the high success
>> with parameterization of the ligands at the lowest level of the GAFF FF.
>>
>>
> It should be *incredibly* easy to circumvent the constant spacing
> limitation - simply break your transformation into two stages with
> different spacings. There is no requirement that your endpoints correspond
> to 0.0 and 1.0.
>
>
>
>> Well, I think it will not be my only benefit to have a check on other
>> settings that I used above. It would be sad moving to 800 windows while
>> carrying out a systematic error.
>> I only mention below some settings that might turn to be unclear to
>> anyone from the ligand-protein tutorial. Thus, with reference to the
>> terminology used in the tutorial:
>>
>> (1) I first carried out "Restraints:Unbound" getting rest-01 and rest-02
>> coor/vel/xsc
>>
>> (2) As initial bincoord/ve/xsc I used throughout rest-02 for frwd and
>> rest-01 for back. The choice was based on the way rest-01 and rest-02 were
>> obtained.
>>
>> (3) I used npt-04_frwd.fep (-1.00 in column B) and npt-04_back.fep (1.00
>> in column B).
>>
>> (4) alchOutFreq 2000
>>
>> In all that, it still strikes me that back should not be forced to use
>> the coor from the last frwd window.
>>
>> Thanks a lot for your advice.
>>
>> cheers
>> francesco
>>
>> On Fri, Apr 13, 2018 at 5:03 PM, Brian Radak <brian.radak_at_gmail.com>
>> wrote:
>>
>>> Something tells me this is a filesystem error, although it might be
>>> related to NAMD behavior.
>>>
>>> How frequently are you writing to disk? It looks like you are writing a
>>> restart file every 500 steps, which is incredibly frequent and stresses
>>> both NAMD performance and the disk. Even writing energies to output that
>>> frequently can measurably slow down a simulation.
>>>
>>> On Fri, Apr 13, 2018 at 3:49 AM, Francesco Pietra <chiendarret_at_gmail.com
>>> > wrote:
>>>
>>>> Today, while some other FEPs finished regularly, another FEP (frwd-10)
>>>> of the group illustrated above crashed at window 32
>>>> (i.e., 8 windows before completion) with the same issue
>>>>
>>>> WRITING EXTENDED SYSTEM TO RESTART FILE AT STEP 500000
>>>>> TCL: Running FEP window 32: Lambda1 0.9774999999999984 Lambda2
>>>>> 0.9799999999999983 [dLambda 0.0024999999999999467]
>>>>> TCL: Setting parameter firsttimestep to 0
>>>>> TCL: Setting parameter alchLambda to 0.9774999999999984
>>>>> Info: NONBONDED TABLE R-SQUARED SPACING: 0.0625
>>>>> .......................
>>>>> ......................
>>>>> EP: 73500 130.5390 -9397.2284 901.6677
>>>>>
>>>>> WRITING EXTENDED SYSTEM TO RESTART FILE AT STEP 73500
>>>>> colvars: Synchronizing (emptying the buffer of) trajectory file
>>>>> "frwd-09_0.colvars.traj".
>>>>> colvars: Writing the state file "frwd-09.colvars.state".
>>>>> WRITING COORDINATES TO DCD FILE frwd-09.dcd AT STEP 74000
>>>>> WRITING COORDINATES TO RESTART FILE AT STEP 74000
>>>>> FATAL ERROR: Unable to open binary file frwd-09.coor: File exists
>>>>>
>>>>
>>>> This message is also forwarded to the cluster as either a bug exists
>>>> with namd FEP, or there are defective nodes (it was job ID 695703, about
>>>> which "scontrol show 695703" answers "invalid job ID", while I am deleting
>>>> all generated frwd-10 files and restarting)
>>>>
>>>> francesco
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 12, 2018 at 10:28 PM, Francesco Pietra <
>>>> chiendarret_at_gmail.com> wrote:
>>>>
>>>>> Hello
>>>>> I am carrying out with namd2.12 a FEP for Unbound ligand in water (as
>>>>> a preliminary for ligand-protein complex) using 10 segments frwd and
>>>>> 10 back, for a total 400 windows frwd and same back.
>>>>>
>>>>> Segment back-02 has already completed. Out of all other running,
>>>>> frwd-09 crashed at step 54,000 of first window
>>>>>
>>>>> colvars: The restart output state file will be "frwd-09.colvars.state".
>>>>>> colvars: The final output state file will be
>>>>>> "frwd-09_0.colvars.state".
>>>>>> FEP: RESETTING FOR NEW FEP WINDOW LAMBDA SET TO 0.8 LAMBDA2 0.8025
>>>>>> FEP: WINDOW TO HAVE 100000 STEPS OF EQUILIBRATION PRIOR TO FEP DATA
>>>>>> COLLECTION.
>>>>>> FEP: USING CONSTANT TEMPERATURE OF 300 K FOR FEP CALCULATION
>>>>>> PRESSURE: 0 -368.104 569.455 -539.08 569.454 -304.251 -1415.15
>>>>>> -539.08 -1415.15 181.994
>>>>>> GPRESSURE: 0 -260.121 387.556 -718.786 295.641 -123.294 -1219.32
>>>>>> -365.275 -1092.12 269.401
>>>>>> ETITLE: TS BOND ANGLE DIHED
>>>>>> IMPRP :
>>>>>> ...................................
>>>>>> .....................................
>>>>>> WRITING EXTENDED SYSTEM TO RESTART FILE AT STEP 53500
>>>>>> WRITING COORDINATES TO DCD FILE frwd-09.dcd AT STEP 53500
>>>>>> WRITING COORDINATES TO RESTART FILE AT STEP 53500
>>>>>> FINISHED WRITING RESTART COORDINATES
>>>>>> WRITING VELOCITIES TO RESTART FILE AT STEP 53500
>>>>>> FINISHED WRITING RESTART VELOCITIES
>>>>>> colvars: Synchronizing (emptying the buffer of) trajectory file
>>>>>> "frwd-09_0.colva
>>>>>> rs.traj".
>>>>>> colvars: Writing the state file "frwd-09.colvars.state".
>>>>>> WRITING COORDINATES TO DCD FILE frwd-09.dcd AT STEP 54000
>>>>>> WRITING COORDINATES TO RESTART FILE AT STEP 54000
>>>>>> FATAL ERROR: Unable to open binary file frwd-09.coor: File exists
>>>>>> [0] Stack Traceback:
>>>>>>
>>>>>
>>>>>
>>>>> I had never encountered such a problem and wonder whether this stems
>>>>> from the code or the cluster (each FEP on one node, 36 core, NextScale).
>>>>> frwd-09.coor (which is bincoor) has normal size (did not try with
>>>>> psf/vmd), while, curiously, frwd-09.dcd and frwd-dcd.BAK were generated
>>>>> alongside back-09.fepout and back-09.fepout.BAK, as if the dcd and fepout
>>>>> files had been present initially (but they were not). Also, no anomaly can
>>>>> be seen in frwd-09.namd and frwd-09.job.
>>>>>
>>>>> At any event, I am deleting all generated frwd-09 files and
>>>>> restarting from scratch in the hope that it was a non systematic error.
>>>>>
>>>>> thanks for advice
>>>>> francesco pietra
>>>>>
>>>>
>>>>
>>>
>>
>

This archive was generated by hypermail 2.1.6 : Sat Dec 14 2019 - 23:19:45 CST