Skip to content

Commit

Permalink
revisions
Browse files Browse the repository at this point in the history
  • Loading branch information
ljwoods2 committed Oct 9, 2024
1 parent 6dacb8d commit 6d31caa
Showing 1 changed file with 53 additions and 11 deletions.
64 changes: 53 additions & 11 deletions docs/source/protocol_v3.rst
Original file line number Diff line number Diff line change
@@ -1,17 +1,38 @@
IMDv3 Protocol
==============

IMDv3 is a protocol for communicating molecular simulation data through a socket.
It allows for two-way communication: via IMDv3, a simulation engine sends data to a receiver
IMD (Interactive Molecular Dynamics) is a protocol for communicating molecular simulation
data through a socket.
It allows for two-way communication: via IMD, a simulation engine sends data to a receiver
and the receiver can send forces and certain requests back to the simulation engine.

Version numbers in IMD are monotonically increasing integers.
IMDv3, the protocol version described in this document, builds upon IMDv2, the protocol version
implemented at the time of writing in NAMD, VMD, HOOMD, GROMACS, and LAMMPS. IMDv2 is itself
a modification of the original IMD protocol published in 2001 [IMDv1]_.

.. list-table::
:widths: 10 30
:header-rows: 1

* - IMD Version
- Protocol specification
* - 1
- [IMDv1]_
* - 2
- No official specification, but sample protocol and API implementation available [IMDv2]_.
Some characteristics of the IMDv2 protocol mentioned in this document are inferred from commonalities in existing IMDv2 implementations.
* - 3
- This specification

Terms
-----
**Simulation engine**: The producer of simulation data which listens for a receiver connection and sends it simulation data

**Receiver**: The receiver of simulation data, connects to listening simulation engine and receives simulation data through a socket

**IMD frame**: A simulation frame in which IMD data will be sent from the simulation engine to the receiver
**IMD frame**: A simulation integration step in which IMD data will be sent from the simulation engine to the receiver. The IMD
transmission rate defines which integration steps are IMD frames.

**IMD system**: The subset of all atoms in the simulation for which the simulation engine can output IMD data
and for which the receiver can send forces to the simulation engine to apply to.
Expand Down Expand Up @@ -61,43 +82,60 @@ This table lists all header types available in IMDv3. Below, each header type
and its associated body packet (if present) is described in detail.

.. list-table::
:widths: 10 10
:widths: 10 10 10
:header-rows: 1

* - Header type
- 32-bit integer enum value
- Present in IMDv2
* - Disconnect
- 0
- Yes
* - Energies
- 1
- Yes
* - Coordinates
- 2
- Yes
* - Go
- 3
- Yes
* - Handshake
- 4
- Yes
* - Kill
- 5
- Yes
* - MD Communication
- 6
- Yes
* - Pause
- 7
- Yes, but acts as toggle in IMDv2. See `Pause`_
* - Transmission rate
- 8
- Yes
* - IO Error
- 9
- Yes
* - Session info
- 10
- No
* - Resume
- 11
- No
* - Time
- 12
- No
* - Box
- 13
- No
* - Velocities
- 14
- No
* - Forces
- 15
- No

Disconnect
^^^^^^^^^^
Expand Down Expand Up @@ -242,7 +280,7 @@ Pause

Sent from the receiver to the simulation engine any time after the `Session info`_
has been sent to request that the simulation
engine blocks execution until a `Resume`_ packet is sent. Unlike in IMDv2, pause is idempotent,
engine pauses execution of the simulation until a `Resume`_ packet is sent. Unlike in IMDv2, pause is idempotent,
meaning sending a pause packet multiple times in a row will not toggle the
state of the simulation. Instead, subsequent pause packets sent after the first one will have no effect.

Expand Down Expand Up @@ -369,7 +407,7 @@ velocities were previously specified for this session in `Session info`_.
<array> (float32[n_atoms * 3]) X, Y, and Z components of the velocities
of each atom in the
IMD system encoded in the order
[X1, Y1, Z1, ..., Xn, Yn, Zn]
[Vx1, Vy1, Vz1, ..., Vxn, Vyn, Vzn]
Forces
^^^^^^
Expand All @@ -387,15 +425,15 @@ forces were previously specified for this session in `Session info`_.
<array> (float32[n_atoms * 3]) X, Y, and Z components of the forces
of each atom in the
IMD system encoded in the order
[X1, Y1, Z1, ..., Xn, Yn, Zn]
[Fx1, Fy1, Fz1, ..., Fxn, Fyn, Fzn]
Packet order
------------

After the simulation engine sends the `Handshake`_ and `Session info`_
to the receiver and gets back a `Go`_ signal, it beings sending
IMD frames. The data within each IMD frame is always sent in the same, fixed order
in IMDv3:
to the receiver and gets back a `Go`_ signal, it begins sending simulation data via
IMD. The data within each IMD frame is always sent in the same, fixed order
in IMDv3. This is a break from IMDv2 in which any packet order is acceptable.

1. Time
2. Energy block
Expand All @@ -411,7 +449,7 @@ remaining packets in the session.
Units
-----

The units in IMDv3 are fixed. The simulation engine must convert
Like in IMDv2, the units in IMDv3 are fixed. The simulation engine must convert
values into these units before sending them through the socket.
The receiver must also convert forces it sends back to the simulation
engine into these units.
Expand All @@ -434,4 +472,8 @@ engine into these units.
* - Energy
- kilojoules/mol

References
----------

.. [IMDv1] https://doi.org/10.1145/364338.364398
.. [IMDv2] https://www.ks.uiuc.edu/Research/vmd/imd/

0 comments on commit 6d31caa

Please sign in to comment.