Fwd: Ligand atoms moving too fast with FEP

From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Tue Feb 20 2018 - 02:08:17 CST

Mail escaped my control: actually my FEP is running NPT, like in the 2017
tutoriual:

 CONSTANT-T

langevin on
langevintemp 300.0
langevindamping 2.0

# CONSTANT-P

langevinpiston on
langevinpistontarget 1
langevinpistonperiod 100
langevinpistondecay 100
langevinpistontemp 300

---------- Forwarded message ----------
From: Francesco Pietra <chiendarret_at_gmail.com>
Date: Tue, Feb 20, 2018 at 8:58 AM
Subject: Fwd: namd-l: Ligand atoms moving too fast with FEP
To: brian.radak_at_gmail.com, NAMD <namd-l_at_ks.uiuc.edu>

I recognize now that my previous post was somewhat misleading.

First, as I am following the 2017 tutorial, I am carrying out FEP at NVT in
explicit water, charmm36.

Second, I suspected that previous crash by ligand atoms moving too fast at
beginning FEP was due to incomplete equilibration of the system. That was
the case. After longer NPT equilibration of the system, now NVT FEP is
running from 3hr on six nodes (204 core) at 0.1days/ns. I hope that six
nodes are enough to complete the simulation, as I am limited to 24h. Given
the size of the system (81,000 atoms) more that six nodes could not help.

QUESTION: It is not easy for me understanding at which stage the simulation
is, without reading line-by-line namd's log. Are there commands to verify
the progress of the simulation? FEP analysis requires that the simulation
is completed, because of analytical tools limimitation, as far as I know.

thanks

francesco

---------- Forwarded message ----------
From: Francesco Pietra <chiendarret_at_gmail.com>
Date: Fri, Feb 16, 2018 at 4:31 PM
Subject: Re: namd-l: Ligand atoms moving too fast with FEP
To: Brian Radak <brian.radak_at_gmail.com>
Cc: namd-l <namd-l_at_ks.uiuc.edu>

I meant NTP MD at ts=0.1fs, not minimization, which does not feel the value
of ts. Actually, however, I checked that NTP with ts=1.0fs does not crash
on the cluster, so that I launched a one-day long NPT on two nodes (72
cpus). After that, I'll also have (hopefully) a better conformation of the
ligand to use as reference structure for FEP (the starting structure of the
ligand is from NMR; it is a compound that we isolated long ago from
corals). Clearly - as yoy supposed - that ligand atom were moving to fast
was due to the conditions for FEP.

I understand now that you meant NVT. I'll try to educate myself about NVT,
about which I have no experience. I want to simulate human-body conditions
as closely as possible. This is why I choose NTP.

thanks
francesco

On Fri, Feb 16, 2018 at 2:47 PM, Brian Radak <brian.radak_at_gmail.com> wrote:

> On Thu, Feb 15, 2018 at 10:47 AM, Francesco Pietra <chiendarret_at_gmail.com>
> wrote:
>
>> Hi Brian:
>>
>> I generally don't recommend NpT simulations for FEP
>>>
>>
>> I was following the tutorial, which in other quite similar cases worked
>> well under NPT. At any event, as there is no membrane, which other type of
>> simulation?
>>
>
> This is certainly just my opinion and not necessarily the prevailing
> wisdom. My understanding is that NVT generally has about 5-10% better
> performance. It should also give nearly identical results for a well chosen
> density.
>
>
>>
>>
>> I commonly make the mistake of not correctly flagging atoms in the PDB
>>>
>>
>> I am prone to follow your experience with FEP, and I could easily
>> mismatch those flags. But should that be corrected later?
>>
>
> I meant forgetting to flag an atom that should be included in the ligand.
> That's just such a silly mistake that I look for it first (and has solved
> the issue more times than I care to admit).
>
>
>>
>> make sure that you are flagging the atoms to start at the correct, fully
>>> interacting, endpoint. Assuming you are scanning alchLambda 0 -> 1, the
>>> flag should be -1, not 1.
>>>
>>
>> I am at frwd-01.namd and filename.fep flags are -1.00
>>
>> Thanks for answering and beg pardon for what I might have misunderstood
>> from your mail.
>>
>> francesco
>>
>> PS I had just submitted to the cluster a NPT MD with the FEP system and
>> with ts=0.1fs to see what happens. Sometimes files run on inexpensive GPUs
>> are not well transferable.
>>
>
> I'd be a bit surprised if the equilibrated inputs are just "no good" for
> FEP. I guess you could minimize and randomize velociites before doing FEP?
> I've personally never had a situation where the solution was to use a
> smaller timestep during equilibration.
>
>
>
>>
>> On Thu, Feb 15, 2018 at 3:27 PM, Brian Radak <brian.radak_at_gmail.com>
>> wrote:
>>
>>> I generally don't recommend NpT simulations for FEP (unless you have a
>>> membrane) - the virial is goofy for dual-topology simulations, but
>>> doubtfully catastrophically so. That's probably not the issue at all, but
>>> it's something to try.
>>>
>>> At the risk of being slightly insulting, I commonly make the mistake of
>>> not correctly flagging atoms in the PDB - maybe check the ALCH summary
>>> after the PSF STRUCTURE SUMMARY? Also a silly error, but worth checking.
>>> Also, make sure that you are flagging the atoms to start at the correct,
>>> fully interacting, endpoint. Assuming you are scanning alchLambda 0 -> 1,
>>> the flag should be -1, not 1.
>>>
>>> HTH,
>>> BKR
>>>
>>>
>>> On Thu, Feb 15, 2018 at 3:00 AM, Francesco Pietra <chiendarret_at_gmail.com
>>> > wrote:
>>>
>>>> Hallo:
>>>>
>>>> While I had no problems so far with protein-ligand FEP, with a new
>>>> similar ligand, parameterized for charmm36 at the same quality level as
>>>> before for the other ligands, FEP crashed.
>>>>
>>>> The new system had been subjected to charmm36 npt MD for 1,000,000
>>>> steps at ts=1.0fs on a single node CPU-GPU box, reaching constant rmsd vs
>>>> frame. With frwd FEP, carried out on a nextscale cluster on two Broadwell
>>>> nodes (72 cores) at ts=1.0fs, the simulation crashed nearly immediately
>>>> (within 19s) with three atoms of the ligand moving two fast.
>>>>
>>>> What about resubmitting classical MD on the cluster for > 1,000,000
>>>> steps? Or what could be better?
>>>>
>>>> thanks for advice
>>>>
>>>> francesco pietra
>>>>
>>>
>>>
>>
>

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