Next: How the Connection
Up: No Title
Previous: Making Stereo Raster
???? COMBINE WITH OR MOVE TO MDCOMM DOCUMENTATION ????
???? OR SHARE???????? I'LL SHARE ????
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 coordinate timesteps
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.
MDComm
anonymous ftp directory.
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.
Next: How the Connection
Up: No Title
Previous: Making Stereo Raster
Andrew Dalke
Tue May 14 16:49:45 CDT 1996