Mon, 8 Sep 1997 12:31:00 -0700
> 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.
Regardless, you are tying topology generation together
with the force field. If I want to try something different,
like MM3 or use dihedral dynamics, I want some way to override
the default mechanism. But I'll defer conversation on this
until I've had a chance to think more about it. The upcoming
Python conference should be fun!
> 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 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
2) once the system has been tweaked, I can present the complete
description in a form easily used by other programs. When I was
at UIUC this made it very easy for us to start working on an MD
program; we would use XPLOR to generate the topology, and work
from there, making NAMD a nearly drop-in replacement for the
simulation component of XPLOR.
> 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.
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.
> MMTK tries to follow standard chemistry usage: molecules consist of
> atoms and/or functional groups, and residues are just special
> functional groups.
What's an example of a functional group that should be distinguished
from a residue?
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
statement of a charge group, since I think it is best done
automatically, but it is something to bear in mind.
> > 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
Oops, I wasn't clear enough in my statement.
I've seen some class hierarchies that look like:
the system is
a set of molecules
which are sequences
but I think the extra layer describing molecules as inheritently
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
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.
Its a somewhat philosophical point, I know, since you can always
have a residue be in a sequence of length 1.
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
> 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...
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 would imagine that I register a callback for certain
> > classes of events. When I execute the user command, I
> > would flag when specific events came back, and act on them
> > after the user command has been completed. (In that way,
> But that requires another notification to indicat the command
> is completed. At least in a multi-threading environment.
But that notification is in another place. Somewhere code I
wrote called MMTK. That code knows when the calls to MMTK
terminated and at that point can issue a new event to have others
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
more time figuring out MMTK and look forward to the next release,