From: Ajasja Ljubetič (ajasja.ljubetic_at_gmail.com)
Date: Thu Feb 02 2012 - 09:06:37 CST
>
> Hum, this is a very peculiar situation... I wish you had defined the
> variable in terms of atoms that move together with the peptide (such as
> certain side chains) instead of dummy atoms if you were planning on
> allowing the protein to move later.
I was thinking about this too, but I didn't want to be limited only to
alpha-helices, for example I would like to preform the same calculation on
a beta-sheet structure. So I was not sure which side chains atoms would
always be in the correct location.
Is there any other (theoretical or practical) consideration why defining
the colvar in this way is a bad idea? The one oneSiteSystemForce options
seems to work nicely, and the simulation seems stable.
>
In any case, I don't believe you need to rotate the dummy atoms. The dummy
> atoms won't drift or rotate with the protein. Instead, it's the protein
> atoms that you should fit using the initial structure to go back to the
> frame where the protein didn't move. So you only apply the fitting options
> to group1.
>
Yes, you are absolutely right! I completely forgot that I can (actually
have to) transform only one group of the colvar component.
> Regarding why the PDB file doesn't work, you need to match the number of
> coordinates of the atoms that you use for fitting (refPositionsGroup), not
> the number of atoms of group1. The problem in providing a file with the
> whole system is that the PDB reader will by default read the coordinates of
> group1, not those of refPositionsGroup.
Aha, I thought that it would take the indices of the refPositionsGroup and
only load those from the PDB.
> If you write a PDB file that just contains the five positions of the
> refPositionsGroup atoms, it should work.
Thank you, this works! For completeness I'm pasting the working version
below. (It was quicker for me to just paste the positions into
refPositions).
dihedral {
oneSiteSystemForce
group1 { atomnumbers 173 174 175 176 177 181 185 189 193 194
rotateReference on
centerReference on
refPositionsGroup {atomnumbers 200 202 204 208 209}
refpositions
(0.9959999918937683,-1.2680000066757202,-0.7979999780654907)
(2.0460000038146973,-0.8029999732971191,0.07900000363588333)
(3.1630001068115234,-0.061000000685453415,-0.6990000009536743)
(1.49399995803833,0.12099999934434891,1.1390000581741333)
(1.8849999904632568,0.041999999433755875,2.3010001182556152) } ;
group2 { dummyAtom
(3.1630001068115234,-0.061000000685453415,-0.6990000009536743) } ;
group3 { dummyAtom
(3.1630001068115234,-0.061000000685453415,9.300999999046326) } ;
group4 { dummyAtom
(13.163000106811523,-0.061000000685453415,9.300999999046326) } ;
}
}
Update:
I analysed the first 50 ns of the simulation with the new coordinate
system. The result does not match the previous one (the PMF seems
distorted). I'm almost 100% I made some mistake in the configuration file,
but just to be sure, could you comment on the following two warnings?
- From the manual under rotateReference/centerRefrence:
*"Note*:*the derivatives of the colvars with respect to the
rotation/translation are usually neglected (except by *rmsd* and *
eigenvector*)*."
What exactly does this mean? Does this come into play when
the Cartesian biasing force is calculated (eq
4<http://www.edam.uhp-nancy.fr/ABF/theory.html>)
from the colvar derivative? (BTW there is still a small typo in that
equation - the gradient should be along Cartesian coordinates and not
along colvars space).
- From the log file:
"Warning: atom group "group1" is set to be rotated to a reference
orientation: a torque different than zero on this group could make the
simulation unstable. If this happens, set "disableForces" to yes for this
group."
If I understand rotateReference/centerRefrence correctly, the atoms
in the group are first rotated and translated to best superimpose with
the reference positions, then the value of the colvar is calculated (and
the derivative at that point) and the Cartesian forces are estimated from
the average forces on the colvars in this bin. Then this Cartesian forces
are rotated back into the original reference frame. In my case this
almost certainly result in a non zero torque, but the simulation still
seems stable. Should I be worried about this non-zero torque?
Again, thank you very much & best regards,
Ajasja
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2012 - 23:21:10 CST