Next: 10.1 How the Connection
Up: No Title
Previous: 9.4 Making Stereo Raster
VMD has the capability to work with a molecular dynamics program
running on another computer, in order to display the results of a
simulation as they are calculated. As new atomic coordinates
are generated by the simulation process, they can be transferred
directly over the network to VMD, which can then animate the
molecule. A major new feature in VMD is the ability to add
perturbative steering forces to a running simulation, which are
incorporated directly into the dynamics calculation.
VMD uses a set of daemons and library routines to provide the communication
and coordination functions necessary to allow connection to a remote
application program. This set of daemons and library routines is known
as MDComm,
written by Rick Kufrin of the National Center for Supercomputing
Applications (NCSA)
.
A version of the MDComm library and daemons are
provided in the standard VMD distribution for use on SGI workstations.
The MDComm source code and documentation are also available from the
MDComm anonymous ftp directory.
See also the
MDComm web page.
In order for VMD to work in this fashion as a graphical front end and
control console for a remote molecular dynamics simulation, several things
are necessary:
- A molecular dynamics program capable of communicating with VMD must
be installed properly on another computer (although it can also be installed
on the same computer used to run VMD, if desired). Right now, there is
one MD program supported by the Theoretical Biophysics group for this purpose,
called NAMD. See
the NAMD WWW home page for information on obtaining
a copy of NAMD. NAMD is a parallel molecular dynamics program written in
C++, which implements the CHARMM energy function. It is compatible with
X-PLOR style PSF, PDB, and parameter files. The rest of the discussion in
this chapter assumes you are using NAMD.
- A master control daemon (the rappd daemon)
must be running on the computer which will be used to run NAMD. This daemon
stores information about what applications are available on that computer to
be started, and also keeps a list of what jobs are currently running on that
computer. VMD communicates with this daemon at the start to find out how
to start up a new job, and then when all parameters have been set up this
daemon will actually launch a new application-specific daemon which will
start NAMD. rappd will also provide to both VMD and
NAMD the information required for them to start talking to each other.
Basically, it is the manager for the whole process.
- A NAMD-specific communication daemon (namdd or simple_namdd)
must be available and installed on the same computer as will run NAMD. When
a new MD job is started by rappd, both a NAMD and a namdd
process are started up. namdd is responsible for buffering the dynamic
data transferred between NAMD and VMD, to make things faster and to help
prevent deadlocks.
- A VMD-specific communication daemon (namd_consumer)
must be available and installed on the same computer which is running VMD.
When a new MD job is started by rappd, at the same time a new
namd_consumer process will be started. Just as namdd is used,
this daemon buffers dynamic data and helps prevent deadlocks.
For a full description of how these processes interact, we again direct
you to the MDComm home page.
Once all these components are in place, you can use the graphical user
interface tools in VMD to start up new MD jobs on a remote computer, view
the results as they are calculated, and control the simulation parameters
via VMD. You can choose to then kill the remote job, or else you can
detach from simulation and leave it running. If you detach from a job, you
can later reattach to that same job and resume visualizing the data at the
current point in the simulation. See
sections on
Remote form,
Sim form,
remote command, and MDScope home page at
MDScope WWW home page
for more information.
Next: 10.1 How the Connection
Up: No Title
Previous: 9.4 Making Stereo Raster
Sergei Izrailev
Fri Jul 25 17:07:27 CDT 1997