From: Chitrak Gupta (chgupta_at_mix.wvu.edu)
Date: Wed Oct 11 2017 - 20:20:24 CDT
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>
> Hi Chitrak,
> Thanks for the prompt reply.
> I am performing FEP/REST2 simulations here (http://www.pnas.org/content/
> 109/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 : Sun Dec 31 2017 - 23:21:43 CST