From: Chitrak Gupta (chgupta_at_mix.wvu.edu)
Date: Thu Oct 12 2017 - 08:21:09 CDT
Ok, so here is my question. In the absence of a FEP-coupling, how do you
know whether or not the sorting was correct?
On Thu, Oct 12, 2017 at 7:50 AM, Bhati, Agastya <agastya.bhati.14_at_ucl.ac.uk>
> The same thing also seems to happen for my REST2 (not coupled to
> FEP) simulations (as the same sortreplicas executable is used for sorting
> in both type of calculations). However, in that case there is no chance of
> such close contacts occurring, and hence, the problem is not immediately
> obvious. So, after I observed this problem in FEP/REST2 simulations, I
> tried to sort the REST2 trajectories again by adding a frame at the
> beginning of the original unsorted trajectories. This improved my results
> May be you wanna give it a go?
> *From:* Chitrak Gupta <chgupta_at_mix.wvu.edu>
> *Sent:* 12 October 2017 02:20:24
> *To:* Bhati, Agastya
> *Cc:* NAMD list
> *Subject:* Re: namd-l: Implementation of sortreplicas executable for
> restarted REST2 simulations
> Ah, I see.
> I have only used REST2 just by itself (i.e. no FEP coupled to it). Maybe
> someone who has done this could provide a good exaplanation.
> On Wed, Oct 11, 2017 at 3:50 PM, Bhati, Agastya <
> agastya.bhati.14_at_ucl.ac.uk> wrote:
>> Hi Chitrak,
>> Thanks for the prompt reply.
>> I am performing FEP/REST2 simulations here (http://www.pnas.org/content/1
>> 09/6/1937.full), where each replica has a different REST2 scaling factor
>> (\sptscale) as well as alchemical paramater (\lambda) and exchanges are
>> attempted between them. The problematic conformations I am referring to
>> here are the ones where an alchemically transforming atom has very close
>> contact with some other atom from rest of the system. This leads to very
>> high values of potential energies and potential derivatives wrt \lambda.
>> Well-behaved in this case means that no such bad contacts are observed in
>> any of the snapshots of the sorted trajectories.
>> Such contacts, in my understanding, can occur only when somehow due to
>> incorrect sorting, the conformations from end-points states (\lambda =0 or
>> 1) end up in one of the intermediate states.
>> Hope that helps. Let me know if you need more clarification.
>> *From:* Chitrak Gupta <chgupta_at_mix.wvu.edu>
>> *Sent:* 11 October 2017 20:32:54
>> *To:* NAMD list; Bhati, Agastya
>> *Subject:* Re: namd-l: Implementation of sortreplicas executable for
>> restarted REST2 simulations
>> Hi Agastya,
>> I have not done FEP but have used the REST2 version you referred to.
>> Could you elaborate why you mean by "well-behaved" and what problem you had
>> in your case 2?
>> On Wed, Oct 11, 2017 at 3:12 PM, Bhati, Agastya <
>> agastya.bhati.14_at_ucl.ac.uk> wrote:
>>> I have been performing FEP/REST2 simulations using the customised NAMD
>>> developed by Sunhwan and Wei (https://doi.org/10.1016/j.cpc.2015.08.030
>>> I observed that sortreplicas executable seems to do correct sorting only
>>> when the trajectory files contain one extra snapshot. Let me elaborate this
>>> point with the following example cases.
>>> - Case 1 (Fresh run): I set "steps_per_run", "runs_per_frame" and
>>> "num_runs" variables as 500, 10 and 4000, respectively. In addition, I run
>>> a 5000 step equilibration before attempting the first exchange. Therefore,
>>> the output trajectories have 401 snapshots. In this case, "sortreplicas"
>>> seems to sort the trajectories correctly with the final sorted trajectories
>>> containing only 400 snapshots. I am not sure what happens to the extra
>>> snapshot here but the sorted trajectories are well-behaved.
>>> - Case 2 (Restarted run): I use the same input parameters as mentioned
>>> in case 1 above for a restarted simulation. Since in this case no
>>> equilibration is done before exchanging begins, the number of snapshots is
>>> 400. In this case, the sorted trajectories, which contain 400 snapshots, do
>>> not behave correctly and have problematic conformations.
>>> - Case 3: I added the last snapshot of the unsorted trajectories from
>>> case 1 to the beginning of the unsorted trajectories from case 2. These
>>> modified trajectories contain 401 snapshots. On sorting these modified
>>> trajectories using sortreplicas, the resultant trajectories have 400
>>> snapshots and are well-behaved.
>>> My conclusion from the above three cases is that sortreplicas appears to
>>> do what is desired only when there is an extra snapshot at the beginning of
>>> the unsorted trajectories. I am not sure why does this happen and how
>>> sortreplicas gets rid of the extra snapshot. Does anyone else experience
>>> similar thing and understand it or am I missing something here and doing
>>> something wrong? If my conclusion is correct, is there a special way of
>>> implementing sortreplicas executable for restarted simulations where no
>>> extra snapshot is present?
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:39 CST