Sat, 6 Sep 1997 18:43:11 +0200
> Let me describe what I did for VMD:
> A "molecule" contains a set of residues and atoms. There could be
> several chemical molecules in a "molecule"
That remains me of the CHARMM way of viewing the world - which
in my opinion is too far away from a normal chemist's point of view.
Viewing a box full of water molecules as a single super molecule
consisting of unconnected residues is more than a bit weird.
MMTK tries to follow standard chemistry usage: molecules consist of
atoms and/or functional groups, and residues are just special
> In general, I think class structures don't map very well to molecular
> structures except for Molecule/Residue/Atom.
I don't see the problem; you can easily define classes for anything
> There are a couple I know of. The "offical" replacement for the
> PDB is mmCIF (http://www.pdb.bnl.gov./mmcif.html) but I can't say
> it is much better. Still has an 80 column limit, uses continuation
> markers and "implicit loops" like fortran code, and doesn't have a
> real idea of objects.
Sounds archaic, but I am willing to live with all that if only the
format is used as documented!
> The other is NCBI's ASN.1 format for MMDB, which provides a
> C-based reader. See http://www.ncbi.nlm.nih.gov/Structure/ .
Thanks, I'll look at both of them...
> Then I misunderstood. I know that xplor lets me pick which
> topologies I want, and I didn't see the equivalent option in MMTK,
> so I figured it was guessing. Actually, they are doing somewhat
> different things. By making you pick the topology file, xplor
> lets you force the topology any way you want, while MMTK picks
> things based on the amount of hydrogens you want.
> Is that correct?
Yes and no, depending on your point of view!
MMTK's equivalent to CHARMM/XPlor topology files are the definitions
in the database. When you construct a protein, MMTK applies a rather
simple mapping from residue names to file names in the Groups directory
of the database. This mapping depends on hydrogenation level and
position in the chain (to deal with the termini). For example,
'ala' gets mapped to one of
where "ct" and "nt" stand for the terminus versions, "noh" stands
for "no hydrogens", and "uni"/"uni2" stands for "united atom"
models ("uni" for Amber91, "uni2" for CHARMM19).
The analogon to changing topology files in XPlor is changing to a
different set of group definitions in MMTK. You could do this by
creating a directory Groups in your work directory (assuming that "."
is on MMTKPATH and before the default database) and putting the
modified definitions in there. However, I do not recommend this,
since you will create systems (and trajectories etc.) that look
standard at first glance but work only with your personal setup.
It's fine of course for a "quick hack".
> > I was surprised too that Amber treats [charges for terminals]
> > differently!
> It does make sense but I wonder about the usefulness of it. I'm
> guessing they used QM to get the charges, and when you start doing
> that I want to know how much the charges are affected by the residue
> neighbors. For instance, how does G-Y affect the charges of the
> tyrosine as compared to H-Y? Also, I can't see why charmm's
> parameters don't do that.
They did use QM to get the charges; the procedure (with some
justification) is explained in the paper on the Amber94 potential
(follow the link in the MMTK manual). In contrast, the CHARMM22 force
field has never been published or described, so hardly anyone knows
how the charges were determined there!
> > > bondlist. How can this be overridden? For example, one
> > This conforms to the Amber94 definition, and it can't be overridden
> > other than by defining another force field.
> Again, this might be showing my inexperience in non-charmm force
> fields. However, I'm looking at charmm22/topallh22x.pro and
> see entries like:
> > PRESIDUE FHEM ! FIX UP THE HEME BY DELETING UNWANTED AUTOGENERATED ANGLES
> > ! unliganded heme patch
In the Amber philosophy, you would define a force field term with a
force constant of zero. A much clearer solution in my opinion, and I
don't really care about the overhead of calculating a small number of
zero potential terms.
The Amber force field provides an explicit force field term in the
parameter file for any bond and bond angle that can occur in the
systems for which it was designed. Dihedrals are treated somewhat
differently: if there is no entry for a given dihedral, it is assumed
to be zero. All bonded terms are always auto-generated. MMTK follows
the same rules in its implementation of the Amber force field, of
> Ions and metals have always been "strange." How does MMTK deal with
> zinc fingers? This is a special case similar to S-S bonds. Thus,
> how can you guarantee the auto-generation will be correct for all the
> possible systems thrown at it and not need some way to override that?
Well, I can't. But I suppose MMTK need not be more clever in applying
the Amber force field than Amber itself!
If I were to implement a force field that requires modification to
autogeneration, I would put an exclusion list in the database
entries, right next to the other force field parameters.
> A way to find the volume of a protein:
> Find the box that encloses the protein
> Extend each side by the length of the largest atom's radius
> Let V be the volume of this box
> Choose N points randomly distributed in the box
> Let P be the number of points "inside" a atom
> The protein volume is (P/N +/- 1/sqrt(N) ) * V
> (Unless I misremember my stats.)
Ah, I see. Yes, that ought to work, but with Lutz Ehrlich's
surface module (based on Frank Eisenhaber's NSC routine), which will
be part of the next MMTK release, this won't be necessary any more!
But it might be fun to provide a second implementation and compare...
Konrad Hinsen | E-Mail: firstname.lastname@example.org
Laboratoire de Dynamique Moleculaire | Tel.: +33-18.104.22.168.28
Institut de Biologie Structurale | Fax: +33-22.214.171.124.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais