Tue, 9 Sep 1997 11:31:21 +0200
> > That remains me of the CHARMM way of viewing the world -
> So it looks like I'll have to read up on the AMBER reference
> before I discuss force fields much more. It is a rather
> different way of looking at the world.
I don't think Amber is that different, except when it comes to
autogeneration of energy terms. Its topology files look much like
CHARMM's. And I must add that I have never used Amber (the program)
> Regardless, you are tying topology generation together
> with the force field. If I want to try something different,
No, not at all. In contrary, my goal was to separate them as much as
possible. For most of MMTK, topolopgy is nothing but the hierarchy of
chemical objects. Even the bonds are used only for visualization. It's
up to the force fields to extract whatever information they need from
this topology plus the specific database entries for force field
Of course the base classes in BondedInteractions and
NonBondedInteractions are written with Amber in mind, so it's easier
to implement an Amber-like force field than another one, but anything
is possible by adding more code (no need to change anything). To give
an example of a very different force field I have been thinking about,
one could use an external ab-initio program as a force field by having
MMTK generate appropriate input files, run the program, and extract
the results from the output. Such a force field would use only atomic
positions and chemical element information.
> like MM3 or use dihedral dynamics, I want some way to override
> the default mechanism. But I'll defer conversation on this
It's not a default mechanism, it's the implementation of the
Amber force field. You'd have to implement a different mechanism
if another force field requires it. Of course that would be done
by subclassing the Amber-oriented base classes and overriding
what needs to be changed.
> I see two related advantages to the CHARMm/XPLOR way:
> 1) if I have something that isn't quite standard, I can add it in
> my script rather than have to add/tweak some files
True. You can do the same in MMTK, but it's undocumented. Maybe I
should change that.
In practice, I find that I need a given topology modification/addition
in more than one program. So I need a separate file for it anyway,
unless I want to repeat the data. In CHARMM, I tended to have
a specialized topology file for each project - which is not far from
the MMTK approach.
My standard MMTK setup is to have "." in MMTKPATH. Then I create a new
subdirectory for each project, in which I put programs, data, etc.
Special database entries are in appropriate database subdirectories.
Then I cd to the work directory and have the right environment. For
archiving and interchange with coworkers, I just tar the whole
> 2) once the system has been tweaked, I can present the complete
> description in a form easily used by other programs. When I was
It's rare to find two programs that read the same input file format,
so I see little practical advantage.
> I couldn't think of a better term than "set of molecules", which
> I considered to be too long and pedantic. Most programs have a
> button like "Load a molecule", which loads all of the available
> molecules in a file, so I don't think too people many have
> strong problems with it.
I know several CHARMM beginners who were quite confused by the fact
that the word "molecule" hardly ever occurs in the CHARMM manual.
And that they have to refer to solvent by a "segment id" and to
a specific solvent molecule by a "residue id".
> What's an example of a functional group that should be distinguished
> from a residue?
A methyl group, for example. See Groups/methyl.
> BTW, I just remembered that charmm also has "charge groups" which are
> used to group sets of atoms of a residue for simplifying charge
> pairwise interactions. (If the distance between the centers of the
> groups is large enough, then you don't have to test the distances
> of each of the members of the charge group.) I don't like the explicit
It's more than just an efficiency trick; doing the cutoff in terms
of neutral groups seems to reduce the cutoff side effects. But this
is clearly a force field problem and should be kept distinct from
> statement of a charge group, since I think it is best done
> automatically, but it is something to bear in mind.
I don't think there is a way to define the groups automatically. They are
designed as part of the charge determination.
> being a sequence is too much. Instead, I like:
> the system is a set of atoms that has various groupings:
> sets of residues (sequences, fragments, molecules)
> This is also reflecting more of a physicist's view than a chemist's
> view, I think. All I really care about are atoms. Higher level
Well, I am physicist myself, but I have come to appreciate a more
detailed structure for a molecular system. For example, a clear
identification of backbone and sidechains in a protein is very
useful in practice. With a CHARMM-like approach, you have to identify
the backbone by atom names, which is messy and error-prone.
> orderings are convient for living processes, but there's no
> fundamental reason for it to exist, so there's no fundamental reason
> for me to put that into my class structure.
The class structure should reflect a user's point of view, not
the program's. There is more to modeling that force field evaluation
and MD: system setup, analysis, visualization, etc. Nevertheless,
modeling programs tend to be designed around force fields and
> BTW, another interesting simulation I've seen is lipids with the
> end of the tail bound to a silicon substrate. This is a case where
> there is no natural sequence ordering, and has the question; is
> each Si atom a residue? Or do all the Si atoms together make a
Neither makes sense. Silicon forms a crystal or an amorphous
glass-like state. I'd describe the first by a special crystal
class, and the second by a collection of atoms with no special
> I just took a look at it. The problem for us is the statement:
> : ASC is freely available for academic use, so you may download it
> : to your site. Commercial users please contact in advance the author
> : Frank Eisenhaber (e.g. via E-mail firstname.lastname@example.org) for
> : a commercial user licence.
> and I'm not at a university anymore. This would also have
> redistribution problems if I were to include it in a package with
> a more lenient policy, like VMD.
I do see the problem, and I don't like such restrictions myself,
but I can't do anything about it. There is however no problem with
redistribution; NSC is available publicly from an FTP site anyway.
It's a bit like the shareware philosophy: everyone can get it,
but you have to pay if you use it outside the academic world.
Anyway, we live in a modular world, and if someone wants to do
another surface/volume calculation module, go ahead...
> I think I'll raise the question of event models to c.l.py and
> see what others say. In the meanwhile, I'm going to spend some
Good idea. It's a sufficiently general problem, and I wouldn't mind
seeing some general-purpose classes, preferably written by someone
Konrad Hinsen | E-Mail: email@example.com
Laboratoire de Dynamique Moleculaire | Tel.: +33-220.127.116.11.28
Institut de Biologie Structurale | Fax: +33-18.104.22.168.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais