From: Jérôme Hénin (jerome.henin_at_ibpc.fr)
Date: Thu Mar 12 2015 - 05:27:07 CDT
Hi Kevin,
NAMD takes the initial coordinates as they are and starts the simulation
without wrapping or unwrapping. The colvars use those coordinates. The
wrapping options only affect output files.
If you want the output files (DCD and coodinates) to reflect what NAMD uses
internally, you should disable wrapping. Then you can load that output in
VMD and calculate the colvars interactively to check their definition.
Jerome
On 12 March 2015 at 07:20, Kevin C Chan <cchan2242-c_at_my.cityu.edu.hk> wrote:
> 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> 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