Re: lengthening time-step with constraints causes RMSD "jump"

From: P.-L. Chau (pc104_at_pasteur.fr)
Date: Thu Jun 02 2011 - 11:23:34 CDT

> There was a bug, fixed in NAMD 2.8, where if the coordinates and consref
> used the same PDB file and a bincoordinates file was specified that the
> coordinates from the bincoordinates file would over-write the shared
> coordinates/consref data and thus shift the constraint positions. The
> workaround for earlier versions is to use a different file name for
> coordinates and consref (even a link will work) so NAMD can't tell that
> it's actually the same file.

Thank you for reminding me of this. I have already used two separate
files, one for coordinates and the other for consref, to stop this "jump"
from occurring (in fact I asked about that problem on 25th May myself), so
I am quite sure this "jump" does not come from that bug.

> If you want "strong" constraints on the protein atoms you should use
> fixed atoms rather than trying to approximate them with harmonic
> restraints.

I froze the atoms in the initial stages of the simulation, but as the
initialisation of the protein simulation progresses, I gradually relax the
constraints on the protein atoms. Initially I use strong constraints, and
I plan to relax the constraints as I go along. So I am afraid I cannot get
away from "strong" constraints using this initialisation scheme. Could I
ask you what you might suggest as an alternative initialisation scheme,
please?

I am also willing to go into the source code myself to find out why this
happened. Could I possibly ask you if you could give me some broad idea of
where (as in, which subroutines) to insert print statements, and which
variables to pay attention to, please? Somehow I could not think of any "a
priori" reason why lengthening the time-step from 0.1fs to 0.2fs should
cause such dramatic structural changes.

Thank you very much.

P-L Chau

email: pc104_at_pasteur.fr
Bioinformatique Structurale
CNRS URA 2185
Institut Pasteur
75724 Paris
France

This archive was generated by hypermail 2.1.6 : Mon Dec 31 2012 - 23:20:22 CST