From: Kevin C Chan (cchan2242-c_at_my.cityu.edu.hk)
Date: Thu Mar 12 2015 - 01:20:46 CDT
Thanks for the reply. Sorry that I sent the previous email off-list.
No there is no minimisation.
I thought about the PBC and I did turn on Wrapall during both simulation. However I have unwrapped my trajectories in VMD and my protein did not have much translation so not crossing any boundaries. So you are saying that the colvar calculation is probably using non-wrapped coordinates so if it starts from wrapped coordinates (coor file), doesn’t it suppose to unwrap first and then calculate? Then what is actually the colvar.traj displaying, wrapped ones or unwrapped ones?
So I have to turn off wrapall every time I utilise colvar in a simulation starting from a coor (wrapped) file? Because it seems to restraining either the “wrapped” or “unwrapped”, I don’t know which, value to my desired value. Or it is just a problem of internal calculation of NAMD and everything indeed is correct?
Besides, for your information, actually both my simulation-1 and simulation-2 starts from coor files and both show different values in colvar.traj compared to VMD analysis of their dcd.
Again thanks in advance,
Kevin
> On 12 Mar, 2015, at 12:17, Aron Broom <broomsday_at_gmail.com> wrote:
>
> is there any minimization before starting simulation 2 that might actually change the value between the end of simulation 1 and the start of 2?
>
> could it perhaps be related to periodic boundary conditions? I'm not sure exactly how this would manifest, but if the colvar calculation used non-wrapped coordinates, whereas your output dcd and coor files are wrapped, that could possibly give different values, and since simulation 2 starts from the coor, it would start from the wrapped condition and look similar to the dcd analysis (maybe). That all being said, in my past experience with colvars and dihedrals, everything seemed pretty foolproof and I recall thinking it handled periodic conditions well, but maybe there is some option that needs checking.
>
>
>
> On Thu, Mar 12, 2015 at 12:05 AM, Kevin C Chan <cchan2242-c_at_my.cityu.edu.hk <mailto:cchan2242-c_at_my.cityu.edu.hk>> wrote:
> Dear Users,
>
> I was asking about the dihedral definition in colvars but I soon find out questions more about colvars so I think it might be better to open a new thread. Following is my colvars inputs and basically I want it to calculate the dihedral angle from 4 selections (that I have made into 4 group.pdb) and use a harmonic spring restraining it to certain value:
>
> colvarsTrajFrequency 100
> colvarsRestartFrequency 1000
>
> colvar {
> name dih
> width 1.0
> outputValue on
>
> dihedral {
> group1 {
> atomsFile ../group2.pdb
> atomsCol B
> atomsColValue 1.0
> }
> group2 {
> atomsFile ../group1.pdb
> atomsCol B
> atomsColValue 1.0
> }
> group3 {
> atomsFile ../group3.pdb
> atomsCol B
> atomsColValue 1.0
> }
> group4 {
> atomsFile ../group4.pdb
> atomsCol B
> atomsColValue 1.0
> }
> oneSiteSystemForce yes
> }
> outputSystemForce yes
> outputAppliedForce yes
> }
>
> harmonic {
> name diah_pot
> colvars dih
> centers -11.0
> forceConstant 10.0
> }
>
> However although it shows perfectly fine inside the colvar.traj, in which the output value under dih is restrained towards the desired value, it is not the case when I use cv plugin in VMD to calculate dihedral (with exactly the same colvars script) for every frame of the dcd. It seems so weird to me.
>
> In addition, when I feed the result coor and vel from this simulation (simulation-1) to the next simulation (simulation-2), the frame 0 of colvar.traj of simulation-2, which suppose to give value of the last frame of simulation-1, however gives the value that VMD cv plugin measures.
>
> I did a number of tests and searches and totally run out of ideas.
>
> Thanks in advance,
> Kevin
>
>
>
>
> --
> Aron Broom M.Sc
> PhD Student
> Department of Chemistry
> University of Waterloo
This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:21:43 CST