**From:** Chitrak Gupta (*chgupta_at_mix.wvu.edu*)

**Date:** Thu Oct 12 2017 - 08:21:09 CDT

**Next message:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Previous message:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**In reply to:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Next in thread:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Reply:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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>

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>
*

*> *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> 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.
*

*>>
*

*>> Regards,
*

*>> Agastya
*

*>> ------------------------------
*

*>> *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?
*

*>>
*

*>>
*

*>> Chitrak.
*

*>>
*

*>> On Wed, Oct 11, 2017 at 3:12 PM, Bhati, Agastya <
*

*>> 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.030
*

*>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__doi.org_10.1016_j.cpc.2015.08.030&d=DwMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=6cQ04kjNHUuxT8SDe1wb0TtPDsnWRp4T4iwoYRLFpsY&m=iYHh4vTG25qMGbudNyRq1tDEXC3Ijq_uGW99UNobCxs&s=eLtvl2d81XgMvsSgAlE2STw8uHNjiWSde7D6MMI72Rs&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=>
*

*>>>
*

*>>
*

*>>
*

*>
*

**Next message:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Previous message:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**In reply to:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Next in thread:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Reply:**Bhati, Agastya: "Re: Implementation of sortreplicas executable for restarted REST2 simulations"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

*
This archive was generated by hypermail 2.1.6
: Sun Dec 31 2017 - 23:21:43 CST
*