Re: Implementation of sortreplicas executable for restarted REST2 simulations

From: Bhati, Agastya (
Date: Wed Oct 11 2017 - 14:50:46 CDT

Hi Chitrak,

Thanks for the prompt reply.

I am performing FEP/REST2 simulations here (, 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 <>
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 <<>> wrote:


I have been performing FEP/REST2 simulations using the customised NAMD developed by Sunhwan and Wei (>). 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:38 CST