Package version of MMTK

Konrad Hinsen
Thu, 11 Feb 1999 21:12:04 +0100

Although this list has been quite for a while, MMTK development is
steadily progressing, and a new release is not too far away (but no, I
don't promise a release date yet). The major new features will be
Ewald sums for electrostatic interactions, thermostats, barostats, and
distance constraints for MD, and support for nucleic acids. I aill
also include my deformation force field for protein normal mode
calculations, which is currently distributed separately.

I would also like to take the opportunity to reorganize MMTK, which has
grown quite a but since the first release. Currently, MMTK appears to
the user as a single module containing everything. But behind the scenes
there are many individual modules, and the current setup means that
everything gets loaded once you import the module "mmtk". This takes
time and memory.

Another problem with the current "monolithic" approach is that there
is no straightforward way to add extensions. This is mainly a problem
for people other than me, who wish to provide their MMTK extensions
to the public.

The solution to both problems is to turn MMTK into a package. Packages
are a feature introduced with Python 1.5 (which I suppose everybody is
using by now!). Essentially, a package is a "supermodule" containing
nested modules. The MMTK package would only include the most basic
objects directly, with everything more specialized contained in
submodules. Submodules would then only be loaded when needed, and
anyone could provide additional submodules (or even subpackages)
to add features to MMTK.

The major consequence for you as a user would be a changed import
sequence at the beginning of your scripts. I will probably provide a
"compatibility module" with the next release that will allow you to
reuse old scripts without modification, but this will be a transition
feature, to be discontinued in later versions.

Unfortunately, the import sequence can only become more complicated.
In my current "design study", I have chose a very fine-grained
division, meaning that most scripts would require many separate
import statements. To given an example, the normal mode example
from the current MMTK distribution (file Examples/
would look like this:

-- File ----------------------------------------------------------
from MMTK import *
from MMTK.Proteins import Protein
from MMTK.Forcefields import Amber94ForceField
from MMTK.NormalModes import NormalModes
from MMTK.Minimization import ConjugateGradientMinimizer
from MMTK.Visualization import view

# Construct system
world = InfiniteUniverse(Amber94ForceField())
world.protein = Protein('bala1')

# Minimize
minimizer = ConjugateGradientMinimizer(world, log = (0, None, 50, stdout,
minimizer(convergence = 1.e-3, steps = 10000)

# Calculate normal modes
modes = NormalModes(world)

# Print frequencies
for mode in modes:
    print mode

# Show animation of the first non-trivial mode 

I am wondering if this large number of import statements could seem
intimidating. Personally I don't mind; I expect to copy the import
lines from one script to the next during most of my work. But I'd like
to have your opinion on this. It is certainly possible to move some
parts back into the (automatically imported) core, for example
"view" or "Protein" - at the price of automatic imports of modules
that are perhaps not used afterwards.

Any comments are welcome!
Konrad Hinsen                            | E-Mail:
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-
Rue Charles Sadron                       | Fax:  +33-
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais