docs tweaks

docs/source/protocol_current.rst

@@ -4,7 +4,7 @@ IMD Protocol in GROMACS
 =======================
 
 For developers interested in implementing the IMD v2 protocol, this document provides a fairly comprehensive specification of the protocol. 
-The protocol is implemented in the GROMACS in all versions starting from 5.0. The source code can be found
+The protocol is implemented in GROMACS in all versions starting from 5.0. The source code can be found
 in the ``src/gromacs/imd`` directory.
 
 - Version: 2
@@ -170,7 +170,7 @@ Protocol steps
         Energy packet:
           <val> (float32) (1 float with the timestep and 9 floats describing the energy of the system)
       Header:
-          2 (IMD_FCOORDS)
+          2 (int32) (IMD_FCOORDS)
           <val> (int32) (Number of atoms in the system)
 
           Position packet:

docs/source/protocol_proposed.rst

@@ -21,27 +21,32 @@ The suggested changes to the protocol are as follows:
         <val> (bit) (imdwait: true or false)
         <val> (bit) (imdterm: true or false)
         <val> (bit) (wrapped positions: true or false)
+        <val> (bit) (energies included: true or false)
+        <val> (bit) (dimensions included: true or false)
         <val> (bit) (positions included: true or false)
         <val> (bit) (velocities included: true or false)
+
         <val> (bit) (forces included: true or false)
-        <val> (bit) (dimensions included: true or false)
-        
-        "wrapped positions" will be a new ``.mdp`` setting which specifies whether the atoms' positions
-        should be adjusted to fit within the simulation box before sending. This is useful for visualization purposes.
+        <val> (7 bits) (unused)
+
+   "wrapped positions" will be a new ``.mdp`` setting which specifies whether the atoms' positions
+   should be adjusted to fit within the simulation box before sending. This is useful for visualization purposes.
 
 3. The server should wait longer than 1 second (possibly up to 60s) for the go signal so that the client 
    has plenty of time to allocate memory buffers based on the endianness and information on included data types 
    it received in the handshake packet.
 
 4. In the simulation loop, the server will send the client data in this order (if the configuration says to send it)
 
-    i. Dimension data (IMD_DIM) in triclinic vectors
+    i. Energy data (IMD_ENERGIES) unchanged
+
+    ii. Dimension data (IMD_BOX) in triclinic vectors
 
-    ii. Position data (IMD_FCOORDS)
+    iii. Position data (IMD_FCOORDS) unchanged except box adjustments (see 5)
 
-    iii. Velocity data (IMD_VELS) in the same manner as positions
+    iv. Velocity data (IMD_VELS) in the same manner as positions
 
-    iv. Force data (IMD_FORCES) in the same manner as positions
+    v. Force data (IMD_FORCES) in the same manner as positions
 
 5. The server will send a new IMD_EOS (end of stream) packet after the last frame is sent unless the client initiates the disconnection with
    IMD_DISCONNECT.