Exploration of molecular systems with Virtual Reality

Over the last few months I’ve been developing an interactive molecular dynamics platform that supports Virtual Reality (VR). Using the Nano Simbox  framework, I can run a research grade GPU-accelerated molecular dynamics simulation (OpenMM) and visualise it in VR.

Molecular simulations are incredibly complex systems as every atom can interact with every other atom in 3D. For example, many drug design problems are akin to a sort of “3D tetris”, where you try to find a drug with the right shape such that it fit snugly into an enzyme’s active site. Virtual reality is a natural environment for exploring these systems, as the inherently 3D nature of VR interaction means we can at last manipulate the system in an intuitive way.

simbox-argon-betalactamase.gif

Simulation of penicillin binding to beta-lactamase, an enzyme instrumental in antibacterial resistance.

We’ve experimented with a variety of VR solutions, and have found the HTC Vive to be the most robust and enjoyable to use. The fact that you can freely walk around the space and that the controllers are tracked extremely well enables powerful interaction with a simulation. Pulling the triggers on the controllers results in a “force probe” being applied to the selected atoms,  meaning you can influence the simulation in a physically meaningful way.

The visualisation and interaction tool we’ve created opens up some exciting prospects. Simply exploring the molecular structure in 3D and observing how the system responds to interaction can be a powerful way of gaining insight into its mechanisms, but I believe we can take this further.

One of the biggest problems in molecular simulations is the so called ‘rare event problem’: interesting events going from one molecular configuration to another (e.g. protein folding, chemical reactions) may occur on the order of milliseconds or, while we typically our simulations are restricted to the order nanoseconds due to the computational intensity of calculating the interactions between all the atoms. In order to compute metrics that can give insight into the system and be compared against experiment, the event has to be sampled many times in order to converge statistics. This has led to a proliferation of methods that attempt to accelerate the occurrence of rare events so that many short simulations can be used to capture the rare event. In previous work, I made some improvements the Boxed Molecular Dynamics (BXD) algorithm, which is an example of one of these methods.

The problem with many of these methods is that they usually require the researcher to set up in advance a set of variables, called collective variables or reaction coordinates, that govern the event of interest. For example, in a simulation of a drug binding to an enzyme, one of the obvious variables governing the binding is the distance of the drug from the active site: it clearly needs to be minimised. However, there may be other more subtle variables as well, such as the angle of the drug as it approaches the protein, or the position of a particle side-chain of a protein. Determining what these collective variables are requires a mixture of chemical intuition and a large amount of trial and error on the part of the researcher, and limits the ability to automate molecular simulations. For simulations of large biomolecules such as proteins, identifying these collective variables can be extremely difficult as the concerted motions between the atoms are incredibly complex. For example, 1% of proteins in the Protein Data Bank are knotted, but it is not clear why or how they end up in this state.

nanotube-trail.gif

Recording the path a methane molecule takes being pulled through a carbon nanotube.

There are methods that attempt to automatically identify the important collective variables for a particular system, but they typically require an initial path between the states of the system. How do you find this initial path if you don’t know what the
important collective variables are? Finding these paths are exactly what interactive molecular dynamics could be useful for.

In the coming months, I’ll be seeing if we can use interactive molecular dynamics with virtual reality to enable researchers to find paths in molecular simulations, which can then be passed on to path refining and collective variable analysis methods. Combining human intuition with automated methods in this way lead to a workflow that provides enhanced insight to chemical problems more quickly.

 

 

 

 

tying molecular knots in virtual reality

Tying knots in large molecules using our exciting new virtual reality environment.

David Glowacki

Over the past few months, I’ve been playing with a new integrated hardware-software framework that fuses the latest in interactive high-performance computing, the latest in virtual reality, and the latest in research-grade GPU-accelerated molecular physics. It’s really fun, and I’m basically addicted. Since we got it working, I’ve had a steady stream of colleagues knocking on my office door asking me if they can try it out. It’s slightly annoying, because I had intended to be ultra-productive during the summer lull in the academic calendar, but that has hasn’t really worked out… When my colleagues aren’t playing with it, then I’ve struggled to get much work done because I’ve mostly spent time hanging out in VR playing with my favourite molecular simulations…

The video demos a virtual reality port of the Nano Simbox, (aka “Simbox”), a tool which I’ve been developing over the years in collaboration with Bristol-based software firm iSci (aka Interactive Scientific). It lets us manipulate…

View original post 220 more words

Python: Installing PIP and Virtualenv without root

Using virtualenv in combination with pip is a great way to run isolated python environments with all kinds of packages. However if the system you are using does not have pip, easy_install or virtualenv installed system-wide, it’s a little bit tricky to set up.

With some experimentation and some googling (stackoverflow), here’s a quick guide to do it. I’m assuming you have python already on the system.

First, we need ez_setup. The following commands grab the scripts and install them to ~/.local/bin:

wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py
python ez_setup.py –-user

Now we can install pip in the same way:

curl -O https://bootstrap.pypa.io/get-pip.py
python get-pip.py –-user

Now we have pip, and just need to add it to the path variable (add it to your .bashrc):

export PATH=~/.local/bin:$PATH

Finally, we can install packages. Get virtualenv:

pip install --user virtualenv

Now you can set up virtual environments for python, which is well-documented here.

Babun – A terminal emulator for Window

As a scientific programmer, I spent most of my time working on Unix systems, and have grown accustomed to the range of features in various shells. I also develop on Windows occasionally, as in my opinion the Visual Studio IDE is excellent for large projects, and some of my projects currently require it.
I mostly used Git Bash, bundled with the Windows installation of git for my command line needs as it provides just enough to get by. However, I’ve recently been working exclusively on my Windows machine and needed a set up that was slightly more reminiscent of my meticulously crafted oh-my-zsh setup in iTerm2 for OS X. The obvious choice is to configure Cygwin but the effort required is non-trivial.

I stumbled upon Babun, which has done all the hard work for me. It comes with Cygwin, oh-my-zsh, a Mintty console and a whole load of other stuff. Right out of the box, it comes close enough to my usual set up on a unix system to be practical, and doesn’t look like something from the punch-card era. Install tmux with the following command, and nobody will ever know you’re using Windows:

pict install tmux

danceroom Spectroscopy in Bhutan

 

In February I had the unexpected privilege of taking danceroom Spectroscopy to the first Bhutan International Festival, with three other members of the dS team – artist Becca Rose, musician Lee J. Malcolm and University of Bristol PhD student Mike Limb. We transported the gear over 4800 miles to the Himalayan country of Bhutan, a remote Buddhist kingdom rich in history, culture and tradition.

After a 48 hour journey from Bristol to Thimphu, via London, Paris and Delhi, we arrived in the beautiful Centenary park with – to our surprise and immense relief – the dS system all present and in one piece. Setting up dS in Asia in a park for the first festival of it’s kind posed some new challenges, from hair-raising bus journeys through the Paro-Thimphu valley, last minute computer repair in the hotel room, packing down all the equipment every evening to avoid exposing it to sub-zero temperatures, getting repeated electric shocks from dodgy wiring, to manually grounding a geodesic dome to prevent the whole installation from becoming live. Through the ceaseless efforts of the team, the festival organisers, local volunteers and a good amount of duct tape we overcame all the hurdles and successfully ran an installation for the duration of the festival.

The festival was a 10 day extravaganza consisting of arts, live music, film and food; all open to the public.  We ran the dS installation every day peppered with talks, movement workshops and music sessions. Hundreds of locals came and spent time exploring the installation, which is the first of its kind to ever be displayed in Bhutan. Local children in particular spent hours at a time playing games and dancing with one another, then suddenly rushing off only to come back an hour later with more friends. We even had children get into trouble for skipping school to come play!

The theme of the festival was collaboration, with projects between both local and international artists occurring throughout the week. dS has been a collaborative project from it’s inception between artists, scientists, musicians and dancers, so we were well suited to the theme. Interacting and working with so many talented artists from all over the world generated some unforgettable moments, including a spontaneous dance by the Monks of Majuli in the dS dome, with their music and movements blending seamlessly with the soundscape and visuals generated by dS (full video here), and our very own Lee J. Malcolm performing with the Rajasthani folk musician Kutle Khan.

The ten days in Bhutan sped by in a surreal blur of molecular dynamics, incredible music and film, plates of chilli cheese and momos, and visits to remote mountain monasteries above the clouds.  To cap it all off, on the last day of running the installation we were suddenly bundled into a taxi to meet their Majesties the King and Queen of Bhutan, after being fitted with ‘goh’, the Bhutanese formal wear.

I can safely say I never expected my career in computer science to lead to attending such a special event. It was an honour to be included and I hope the Bhutan International Festival continues to be an incredible success in future years, I’ll be back!

Neat Python Debugging Trick

Debugging python is a pretty painless experience using pdb, the built in standard debugger. The basic usage is to insert breakpoints in the code:


import pdb

print('hello world')
print('entering breakpoint')
pdb.set_trace()
sum = 0
for x in range(0, 10):
    sum += x

When the interpreter hits ‘pdb.set_trace()’ it’ll launch the interactive debugging interface, which lets you investigate the different variables, print things and run calculations. A tutorial on using pdb can be found here.

A really useful trick using this snippet allows for quick debugging anywhere in your code. Place the following lines at the top of your python script:

import signal
    def int_handler(signal, frame):
       import pdb
       pdb.set_trace(frame)
signal.signal(signal.SIGINT, int_handler)
Then run the script, and wherever you want to start a debugger press ‘ctrl’+’c’. Press ‘c’ to carry on with execution. Really useful for unpredictable bugs!

Compiling OpenMM as a 64-bit library on Windows

A problem with developing scientific software on Windows is the difficulty in installing scientific packages, which typically provide only very minimal support. To one who isn’t well-versed in CMake, cross-compilation or cygwin, it can be quite daunting. Fortunately, OpenMM, an open source GPU-accelerated molecular dynamics package supporting both CUDA and OpenCL breaks the mould and at the time of writing provides precompiled 32-bit binaries built under Visual Studio 2010 as well as decent instructions on how to compile it yourself. It’s a blazingly fast tool that has run well on every device I’ve tried, while also being extremely flexible (custom forcefield terms automatically turn into optimised OpenCL kernels!). Using it, I’ve been able to develop real-time interactive protein simulations:

For running simulations, downloading the precompiled library and using the python interface should suffice. However, if you want to use OpenMM as a library with an existing C++ application and use a different version of Visual Studio – or your application is 64-bit – you’ll probably need to compile it yourself.

What follows is a short guide for compiling and installing OpenMM 6.0.1 as a 64-bit library for Visual Studio 2012.

Assuming you’ve downloaded OpenMM, and have opened up the user guide (here), follow Chapter 9 ‘Compiling OpenMM From Source’ in that document, but add in the following tweaks for 64-bit.

Once you get to Section 9.2.2.2, when you click Configure and are prompted to select a Generator, choose ‘Visual Studio 12 Win64’, or whatever version you have. Make sure to read through all the options and tick anything you need.

Carry on following the user guide, and try to build it.

You’ll probably get an error like the following:

 error LNK2019: unresolved external symbol __imp_pthread_create referenced in function "public: __cdecl OpenMM::ThreadPool::ThreadPool(int)" (??0ThreadPool@OpenMM@@QEAA@H@Z) C:\Code\Libs\Source\OpenMM\build\ThreadPool.obj OpenMM 

The problem is that OpenMM ships with a 32-bit distribution of pthreads, but is trying to link with a 64-bit version. Thankfully, SimTK have a version available here. Download  ‘pthreadVC2_x64.dll’ and ‘pthreadVC2_x64.lib’. These should live in the directory ‘src\libraries\pthreads\lib\’, where ‘src’ is where you downloaded the OpenMM source. You also need to put them in ‘openmm_build\Release\’.

Now open the Visual Studio solution and change the dependencies for the projects OpenMM, OpenMMCUDA and OpenMMOpenCL (if you’re building these). Do this by right clicking on the project, selecting ‘Project Properties’. In the window that appears, click Link->Input, and in the ‘Additional Dependencies’ field change the ‘pthreadVC2.dll’ to ‘pthreadVC2_x64.dll’. Do that for each project, then try to build again. With a bit of luck, it will work. If anybody alters the CMake configuration to automatically do this, I’d like a copy, as this is a bit of a dirty hack.

Run the unit tests, then build the ‘INSTALL’ project. Once that’s done, navigate to the installation lib directory (‘C:\Program Files (x86)\OpenMM\lib’ by default), and paste the pthread files there too. Make sure you set the environment variables as described in the User Guide, and you should be able to run some MD!