Re: Implementation of sortreplicas executable for restarted REST2 simulations

From: Bhati, Agastya (agastya.bhati.14_at_ucl.ac.uk)
Date: Thu Oct 12 2017 - 09:00:27 CDT

I can't think of any way to confirm if the sorting is correct or not in case of REST2 simulations. Since, in such calculations, the Hamiltonian of a given replica does not vary much from those of others, the results only vary slightly even in case of incorrect sorting. However, comparing the results after sorting with and without extra snapshot can hint towards that. For instance, in my case, I find that results are more accurate after sorting the trajectories with an extra snapshot. In addition, the distribution of energies and energy derivatives is wider on sorting without an extra snapshot.

Agastya
________________________________
From: Chitrak Gupta <chgupta_at_mix.wvu.edu>
Sent: 12 October 2017 14:21:09
To: Bhati, Agastya
Cc: NAMD list
Subject: Re: namd-l: Implementation of sortreplicas executable for restarted REST2 simulations

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<mailto:agastya.bhati.14_at_ucl.ac.uk>> wrote:

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 slightly!

May be you wanna give it a go?

Regards,

Agastya

________________________________
From: Chitrak Gupta <chgupta_at_mix.wvu.edu<mailto: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.

Chitrak.

On Wed, Oct 11, 2017 at 3:50 PM, Bhati, Agastya <agastya.bhati.14_at_ucl.ac.uk<mailto: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/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.

Regards,
Agastya
________________________________
From: Chitrak Gupta <chgupta_at_mix.wvu.edu<mailto: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?

Chitrak.

On Wed, Oct 11, 2017 at 3:12 PM, Bhati, Agastya <agastya.bhati.14_at_ucl.ac.uk<mailto:agastya.bhati.14_at_ucl.ac.uk>> wrote:

Hi,

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.030d81XgMvsSgAlE2STw8uHNjiWSde7D6MMI72Rs&e=>). 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?

Regards,

Agastya
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_IntellectualPromotersGuild&d=DwMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=6cQ04kjNHUuxT8SDe1wb0TtPDsnWRp4T4iwoYRLFpsY&m=iYHh4vTG25qMGbudNyRq1tDEXC3Ijq_uGW99UNobCxs&s=l183ZavDBZC-r-v0w6ibskm62QFQ0esTjm_Qwfb8LNk&e=>

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