# Also in the Article

MD simulation setup
This protocol is extracted from research article:
Sampling molecular conformations and dynamics in a multiuser virtual reality framework

Procedure

The broad strategies that we have previously used to carry out interactive MD (iMD) were outlined by Glowacki et al. (31) and briefly summarized here for the sake of completeness. In classical mechanics, the time-dependent dynamics of molecular systems are solved by numerically integrating Newton’s equations of motion. The vector of forces acting on a set of atoms F(t) can be written in terms of the system’s potential energy V, that is$F(t)=−dVdq$(1)where q is a vector containing the position of each atom in the ensemble. Our system effectively allows users to interactively chaperone a real-time MD simulation by splitting V into two different components$V=Vint+Vext$(2)where Vint corresponds to the system’s internal potential energy, and Vext corresponds to the additional potential energy added when a user exerts a force on a specific atom (or group of atoms) when he/she grabs it using the handheld wireless controller shown in Fig. 1. Substituting Eq. 2 into Eq. 3 then gives$F(t)=−dVintdq−dVextdq$(3)

The external forces were implemented by projecting a spherical Gaussian field into the system at the point specified by the user and applying the field to the nearest atom j through the following formula$dVextdq=mjcσ2(qj−gi)e−‖qj−gi‖22σ2$(4)where mj is the atomic mass of the atom, c is a scale factor that tunes the strength of the interaction, qj is the position of atom j, gi is the position of the interaction site, and σ controls the width of the interactive fields. For all tasks on all the platforms, c was set to 2000 (kJ mol−1)/(atomic mass unit), a value that achieves responsive interaction while preserving dynamical stability, and σ was set to the default value of 1 nm. While an interaction is active, it is always applied to the same atom (or group of atoms), which means that a user can dynamically adjust the course and strength of the interaction by repositioning their field with respect to the atoms with which they are interacting, until he/she decides to “let go.” As discussed in the main text, the position of the interaction field in VR is co-located to precisely where the user’s controller is; for the mouse and touchscreen interfaces, the field is attached to the nearest atom (measured in the 2D plane of the screen). Movements of the field are only possible in 2D, so 3D motions must be built up from successive 2D motions followed by repositioning of the camera.

Simulating the dynamics of a particular molecular system requires specifying an engine to calculate the internal forces. Here, we benefit from the fact that our framework has been designed to flexibly communicate with a wide range of force engines via a defined application programming interface. For the hydrocarbon systems in the nanotube and helicene task, we used our own “in-house” implementation of the MM3 force field (43). The 17-ALA protein knot task used the GPU-accelerated Amber99SB-ILDN force field provided within the OpenMM MD package (34). For the simulation of larger biomolecular systems such as β-lactamase, we used a custom build of PLUMED (35) to communicate with simulations running within OpenMM on a workstation consisting of four NVIDIA 1080 Ti GPUs. This workstation enables us to simulate proteins using the Amber99SB-ILDN force field and optionally include either implicit (for example, continuum) or explicit (for example, TIP3P water) solvent models. In cases where we modeled an explicit solvent, we did not typically visualize the solvent molecules to maintain clarity and high-quality rendering. To integrate the forces, all tasks used a Velocity Verlet integrator, with a Berendsen thermostat (44) set to a target temperature of 200 K. For the nanotube and helicene tasks, a time step of 1 fs was used, while the protein knot task used a time step of 2 fs along with the RATTLE holonomic constraint, owing to the fact that the conformational change occurs over a longer time scale.

To carry out the user studies (detailed further in what follows), the simulations were hosted on separate machines within our own local area network. We used one machine for each task to avoid any latency that might arise from excessive computational load on a single machine. The three machines that we used as simulation servers during user studies included the following: (i) a mid-range gaming desktop with a 3.5 GHz quad-core Intel i5-6600K processor and an NVIDIA GTX 970 graphics card, (ii) a high-end Alienware13 R3 gaming laptop with a 2.6 GHz quad-core Intel Core i7-6700HQ processor and an NVIDIA 1060 dedicated VR graphics card, and (iii) a high-end Alienware15 R3 gaming laptop with a 2.6 GHz quad-core Intel Core i7-6700HQ and an NVIDIA 1070 GTX dedicated VR graphics card. The user tests involving mice (described in the “User study one” section) were run at two different sites: (i) our laboratory at the University of Bristol (UoB), using the mid-range gaming desktop along with an external USB mouse and a 21-inch external monitor and (ii) the CCPBioSim (Collaborative Computational Project for Biomolecular Simulation) 2017 conference using the screen on the Alienware15 along with an external USB mouse. During all user studies, we throttled the performance on all platforms to guarantee that (despite differences in each machine’s specifications) they were capable of running at 30 frames per second. This ensured that the latency across all test platforms gave an equally fluid user experience. For the touchscreen version of the tasks, we used a Samsung Galaxy S3 tablet, connected to the simulation over an 802.11ac Dual Band Gigabit WiFi connection.

Note: The content above has been extracted from a research article, so it may not display correctly.

Q&A