home

Archive for the 'gromacs' Category

GROMACS 5.0.1, nVidia CUDA Toolkit, And FFTW3 Under Ubuntu 14.04 LTS (64-bit); The Virtues Of VirtualBox

Monday, September 22nd, 2014

Summarized below are the catches and fixes from a recent effort to build GROMACS 5.0.1 with FFTW3 (single- and double-precision) and GPU support (so, single-precision). Also, a trick I’ve been doing with great success lately, using a virtual machine to keep my real machine as clean as possible.

0. The Virtues Of VirtualBox

Open source means never having to say you’re sorry.

I’ve made the above proclamation to anyone who’d listen lately who has any interest in using Linux software (because, regardless of what anyone says on the matter, it ain’t there yet as an operating system for general scientific users with general computing know-how). You will very likely find yourself stuck at a configure or make step in one or more prerequisite codes to some final build you’re trying to do, leaving yourself to google error messages to try to come up with some kind of solution. Invariably, you’ll try something that seems to work, only to find it doesn’t, potentially leaving a trail of orphaned files, version-breaking changes, and random downgrading only to find something else stupid (or not) fixed your build problems.

I’ve an install I’m quite happy with that has all of the working code I want on it working – and I’ve no interest in having to perform re-installs to get back to a working state again.

My solution, which I’ve used to great success with GAMESS-US, GROMACS, NWChem, and Amber (so far), is to break a virtual instance in VirtualBox first. For those who don’t know (and briefly), VirtualBox lets you install a fully-working OS inside of your own OS that simply sits as a file in a Virtual VM folder in your user directory. My procedure has been to install a 60 GB VirtualBox instance of (currently) Ubuntu 14.04 (which I will refer to here as PROTOTYPE), fully update it to the current state of my RealBox (updates, upgrades, program installs, etc.), then copy PROTOTYPE somewhere else on the machine. The only limitation of this approach is that VirtualBox doesn’t give you access to the GPU if you’re testing CUDA-specific calculations. That said, it does let you install the CUDA Development Toolkit and compile code just fine, so you can at least work your way through a full build to make sure you don’t run into problems.

When you’re done trashing your VirtualBox after a particularly heinous build, just delete PROTOTYPE from Virtual VM and re-copy your copy back into Virtual VM – voila! You’re ready for another build operation (or to make sure your “final” build actually works flawlessly before committing the build to your RealBox.

That’s all I have to say on the matter. Consider it as your default procedure (at this point, I won’t touch my RealBox with new installs until I know it’s safe in VirtualBox).

1. The State Of My Machine Pre-GROMACS And All Other apt-get’s Used Below

What follows below is pretty straightforward. Errors you might get that don’t appear below might be related to the lack of certain installs on your machine that I installed on VirtualBox. That is, my standard PROTOTYPE comes standard with Intel’s Fortran and C Compilers (for code optimization). Those installs required a few installs above the base Ubuntu install. These are (and are pretty standard anyway, so I say install them anyway):

sudo apt-get install build-essential gcc-multilib rpm openjdk-7-jre-headless 

I could have just installed a fresh version of 14.04 onto a machine to try this myself, but I’m not that motivated. Also, note this list does not include the all-important cmake. We’ll get to that.

And for the rest of GROMACS (at least for older versions), there were lots of mesa/gnuplot/motif-specific dependencies in older versions of GROMACS to build all of the files included in the GROMACS package. Regardless of GPU builds or not, I tend to default to install all the packages below just to have them (which all, for 14.04, currently apt-get properly).

sudo apt-get install openmpi-bin openmpi-common gfortran csh grace menu x11proto-print-dev motif-clients freeglut3-dev libx11-dev libxmu-dev libxi-dev libgl1-mesa-glx libglu1-mesa libglu1-mesa-dev libgl1-mesa-dri libcurl-ocaml-dev libcurl4-gnutls-dev gnuplot

If you don’t install the libblas3gf libblas-doc libblas-dev liblapack3gf liblapack-doc liblapack-dev series, you’ll see the following note from your cmake steps in GROMACS.

— A library with BLAS API not found. Please specify library location.
— Using GROMACS built-in BLAS.
— LAPACK requires BLAS
— A library with LAPACK API not found. Please specify library location.
— Using GROMACS built-in LAPACK.

My own preference is to use the (assumedly newer) Ubuntu-specific libraries from apt-get.

sudo apt-get install libblas3gf libblas-doc libblas-dev liblapack3gf liblapack-doc liblapack-dev

GPU-Specific? One More apt-get

My first passes at proper GPU compilation involved several steps for the nVidia Developer Toolkit install. That’s now taken care of with apt-get, so perform the final apt-get to complete the component/dependency installations.

sudo apt-get install nvidia-cuda-dev nvidia-cuda-toolkit

With luck, your first attempt at a GPU-based installation will look like the following:

[0%] Building NVCC (Device) object src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_copyrite_gpu.cu.o

[100%] Building CXX object src/programs/CMakeFiles/gmx.dir/legacymodules.cpp.o
Linking CXX executable ../../bin/gmx
[100%] Built target gmx

2. Nothing Happens Without cmake

Install cmake! Reproducing the output below to make sure you’re using the same versions for everything (in the event something breaks in the future).

sudo apt-get install cmake

Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
linux-headers-3.13.0-32 linux-headers-3.13.0-32-generic
linux-image-3.13.0-32-generic linux-image-extra-3.13.0-32-generic
Use ‘apt-get autoremove’ to remove them.
The following extra packages will be installed:
cmake-data
Suggested packages:
codeblocks eclipse
The following NEW packages will be installed:
cmake cmake-data
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,294 kB of archives.
After this operation, 16.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://us.archive.ubuntu.com/ubuntu/ trusty/main cmake-data all 2.8.12.2-0ubuntu3 [676 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ trusty/main cmake amd64 2.8.12.2-0ubuntu3 [2,618 kB]
Fetched 3,294 kB in 30s (106 kB/s)
Selecting previously unselected package cmake-data.
(Reading database … 258157 files and directories currently installed.)
Preparing to unpack …/cmake-data_2.8.12.2-0ubuntu3_all.deb …
Unpacking cmake-data (2.8.12.2-0ubuntu3) …
Selecting previously unselected package cmake.
Preparing to unpack …/cmake_2.8.12.2-0ubuntu3_amd64.deb …
Unpacking cmake (2.8.12.2-0ubuntu3) …
Processing triggers for man-db (2.6.7.1-1) …
Setting up cmake-data (2.8.12.2-0ubuntu3) …
Setting up cmake (2.8.12.2-0ubuntu3) …

3. First Pass At GROMACS

The make install step will place GROMACS where you want it on your machine, so you’re just as good building in $HOME/Downloads as you are anywhere else. I will be performing all operations from $HOME/Downloads unless otherwise stated.

According to the GROMACS Installation Manual, your quick-and-dirty install need only involve the following:

$ tar xvfz gromacs-src.tar.gz
$ ls
gromacs-src
$ mkdir build
$ cd build
$ cmake ../gromacs-src
$ make

This allows you build “out-of-source” as they put it. Frankly, I just dive right into the GROMACS folder and have at it.

CMake Error: The source directory “/home/user/Downloads/gromacs-5.0.1/build” does not appear to contain CMakeLists.txt.
Specify –help for usage, or press the help button on the CMake GUI.

And did you see the above error? If so, you read the GROMACS quick-and-dirty procedure backwards. I’m not running it this way, so doesn’t matter to what follows.

My first attempt at building GROMACS produced the following output from PROTOTYPE (reproducing all the text below).

user@PROTOTYPE:~$ cd Downloads/
user@PROTOTYPE:~/Downloads$ gunzip gromacs-5.0.1.tar.gz 
user@PROTOTYPE:~/Downloads$ tar xvf gromacs-5.0.1.tar 

gromacs-5.0.1/README
gromacs-5.0.1/INSTALL

gromacs-5.0.1/tests/CppCheck.cmake
gromacs-5.0.1/tests/CMakeLists.txt

user@PROTOTYPE:~/Downloads$ cd gromacs-5.0.1/
user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=OFF

NOTE: If you just run cmake, you’ll get the following…

cmake version 2.8.12.2
Usage

cmake [options] cmake [options]

… which is to say, cmake requires at least one option be specified. Above, I’m just using -DGMX_GPU=OFF to start the process.

The C compiler identification is GNU 4.8.2
— The CXX compiler identification is GNU 4.8.2
— Check for working C compiler: /usr/bin/cc
— Check for working C compiler: /usr/bin/cc — works
— Detecting C compiler ABI info
— Detecting C compiler ABI info – done
— Check for working CXX compiler: /usr/bin/c++
— Check for working CXX compiler: /usr/bin/c++ — works
— Detecting CXX compiler ABI info
— Detecting CXX compiler ABI info – done
— Checking for GCC x86 inline asm
— Checking for GCC x86 inline asm – supported
— Detecting best SIMD instructions for this CPU
— Detected best SIMD instructions for this CPU – SSE2
— Try OpenMP C flag = [-fopenmp]
— Performing Test OpenMP_FLAG_DETECTED
— Performing Test OpenMP_FLAG_DETECTED – Success
— Try OpenMP CXX flag = [-fopenmp]
— Performing Test OpenMP_FLAG_DETECTED
— Performing Test OpenMP_FLAG_DETECTED – Success
— Found OpenMP: -fopenmp
— Performing Test CFLAGS_WARN
— Performing Test CFLAGS_WARN – Success
— Performing Test CFLAGS_WARN_EXTRA
— Performing Test CFLAGS_WARN_EXTRA – Success
— Performing Test CFLAGS_WARN_REL
— Performing Test CFLAGS_WARN_REL – Success
— Performing Test CFLAGS_WARN_UNINIT
— Performing Test CFLAGS_WARN_UNINIT – Success
— Performing Test CFLAGS_EXCESS_PREC
— Performing Test CFLAGS_EXCESS_PREC – Success
— Performing Test CFLAGS_COPT
— Performing Test CFLAGS_COPT – Success
— Performing Test CFLAGS_NOINLINE
— Performing Test CFLAGS_NOINLINE – Success
— Performing Test CXXFLAGS_WARN
— Performing Test CXXFLAGS_WARN – Success
— Performing Test CXXFLAGS_WARN_EXTRA
— Performing Test CXXFLAGS_WARN_EXTRA – Success
— Performing Test CXXFLAGS_WARN_REL
— Performing Test CXXFLAGS_WARN_REL – Success
— Performing Test CXXFLAGS_EXCESS_PREC
— Performing Test CXXFLAGS_EXCESS_PREC – Success
— Performing Test CXXFLAGS_COPT
— Performing Test CXXFLAGS_COPT – Success
— Performing Test CXXFLAGS_NOINLINE
— Performing Test CXXFLAGS_NOINLINE – Success
— Looking for include file unistd.h
— Looking for include file unistd.h – found
— Looking for include file pwd.h
— Looking for include file pwd.h – found
— Looking for include file dirent.h
— Looking for include file dirent.h – found
— Looking for include file time.h
— Looking for include file time.h – found
— Looking for include file sys/time.h
— Looking for include file sys/time.h – found
— Looking for include file io.h
— Looking for include file io.h – not found
— Looking for include file sched.h
— Looking for include file sched.h – found
— Looking for include file regex.h
— Looking for include file regex.h – found
— Looking for C++ include regex
— Looking for C++ include regex – not found
— Looking for posix_memalign
— Looking for posix_memalign – found
— Looking for memalign
— Looking for memalign – found
— Looking for _aligned_malloc
— Looking for _aligned_malloc – not found
— Looking for gettimeofday
— Looking for gettimeofday – found
— Looking for fsync
— Looking for fsync – found
— Looking for _fileno
— Looking for _fileno – not found
— Looking for fileno
— Looking for fileno – found
— Looking for _commit
— Looking for _commit – not found
— Looking for sigaction
— Looking for sigaction – found
— Looking for sysconf
— Looking for sysconf – found
— Looking for rsqrt
— Looking for rsqrt – not found
— Looking for rsqrtf
— Looking for rsqrtf – not found
— Looking for sqrtf
— Looking for sqrtf – not found
— Looking for sqrt in m
— Looking for sqrt in m – found
— Looking for clock_gettime in rt
— Looking for clock_gettime in rt – found
— Checking for sched.h GNU affinity API
— Performing Test sched_affinity_compile
— Performing Test sched_affinity_compile – Success
— Check if the system is big endian
— Searching 16 bit integer
— Looking for sys/types.h
— Looking for sys/types.h – found
— Looking for stdint.h
— Looking for stdint.h – found
— Looking for stddef.h
— Looking for stddef.h – found
— Check size of unsigned short
— Check size of unsigned short – done
— Using unsigned short
— Check if the system is big endian – little endian
— Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version “2.9.1”)
— Looking for xmlTextWriterEndAttribute in /usr/lib/x86_64-linux-gnu/libxml2.so
— Looking for xmlTextWriterEndAttribute in /usr/lib/x86_64-linux-gnu/libxml2.so – found
— Looking for include file libxml/parser.h
— Looking for include file libxml/parser.h – found
— Looking for include file pthread.h
— Looking for include file pthread.h – found
— Looking for pthread_create
— Looking for pthread_create – not found
— Looking for pthread_create in pthreads
— Looking for pthread_create in pthreads – not found
— Looking for pthread_create in pthread
— Looking for pthread_create in pthread – found
— Found Threads: TRUE
— Looking for include file pthread.h
— Looking for include file pthread.h – found
— Atomic operations found
— Performing Test PTHREAD_SETAFFINITY
— Performing Test PTHREAD_SETAFFINITY – Success
— Could NOT find Boost
Boost >= 1.44 not found. Using minimal internal version. This may cause trouble if you plan on compiling/linking other software that uses Boost against Gromacs.
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so – found
— Setting build user/date/host/cpu information
— Setting build user & time – OK
— Checking floating point format
— Checking floating point format – IEEE754 (LE byte, LE word)
— Checking for 64-bit off_t
— Checking for 64-bit off_t – present
— Checking for fseeko/ftello
— Checking for fseeko/ftello – present
— Checking for SIGUSR1
— Checking for SIGUSR1 – found
— Checking for pipe support
— Checking for isfinite
— Performing Test isfinite_compile_ok
— Performing Test isfinite_compile_ok – Success
— Checking for isfinite – yes
— Checking for _isfinite
— Performing Test _isfinite_compile_ok
— Performing Test _isfinite_compile_ok – Failed
— Checking for _isfinite – no
— Checking for _finite
— Performing Test _finite_compile_ok
— Performing Test _finite_compile_ok – Failed
— Checking for _finite – no
— Performing Test CXXFLAG_STD_CXX0X
— Performing Test CXXFLAG_STD_CXX0X – Success
— Performing Test GMX_CXX11_SUPPORTED
— Performing Test GMX_CXX11_SUPPORTED – Success
— Checking for system XDR support
— Checking for system XDR support – present
— Try C compiler SSE2 flag = [-msse2]
— Performing Test C_FLAG_msse2
— Performing Test C_FLAG_msse2 – Success
— Performing Test C_SIMD_COMPILES_FLAG_msse2
— Performing Test C_SIMD_COMPILES_FLAG_msse2 – Success
— Try C++ compiler SSE2 flag = [-msse2]
— Performing Test CXX_FLAG_msse2
— Performing Test CXX_FLAG_msse2 – Success
— Performing Test CXX_SIMD_COMPILES_FLAG_msse2
— Performing Test CXX_SIMD_COMPILES_FLAG_msse2 – Success
— Enabling SSE2 SIMD instructions
— Performing Test _callconv___vectorcall
— Performing Test _callconv___vectorcall – Failed
— Performing Test _callconv___regcall
— Performing Test _callconv___regcall – Failed
— Performing Test _callconv_
— Performing Test _callconv_ – Success
— checking for module ‘fftw3f’
— package ‘fftw3f’ not found
— pkg-config could not detect fftw3f, trying generic detection
Could not find fftw3f library named libfftw3f, please specify its location in CMAKE_PREFIX_PATH or FFTWF_LIBRARY by hand (e.g. -DFFTWF_LIBRARY=’/path/to/libfftw3f.so’)
CMake Error at cmake/gmxManageFFTLibraries.cmake:76 (MESSAGE):
Cannot find FFTW 3 (with correct precision – libfftw3f for mixed-precision
GROMACS or libfftw3 for double-precision GROMACS). Either choose the right
precision, choose another FFT(W) library (-DGMX_FFT_LIBRARY), enable the
advanced option to let GROMACS build FFTW 3 for you
(-GMX_BUILD_OWN_FFTW=ON), or use the really slow GROMACS built-in fftpack
library (-DGMX_FFT_LIBRARY=fftpack).
Call Stack (most recent call first):
CMakeLists.txt:733 (include)

— Configuring incomplete, errors occurred!
See also “/home/user/Downloads/gromacs-5.0.1/CMakeFiles/CMakeOutput.log”.
See also “/home/user/Downloads/gromacs-5.0.1/CMakeFiles/CMakeError.log”.

Lots of little things to address here. We’ll get to the Boost problem later. Meantime, you can see the critical error is in (1) the lack of FFTW3 and (2) the lack of my specifically asking for -DGMX_BUILD_OWN_FFTW=ON in the cmake process.

NOTE: If you try to fix the FFTW3 problem as described above, you’ll get the following error:

-GMX_BUILD_OWN_FFTW=ON

CMake Error: Could not create named generator MX_BUILD_OWN_FFTW=ON

Make sure to put the “D” in:

-DGMX_BUILD_OWN_FFTW=ON

4. If You Don’t Use DGMX_BUILD_OWN_FFTW=ON To Build FFTW3…

This is a skip-able section if you’re letting cmake do the dirty work (and letting cmake do it is preferred, at least for getting GROMACS built). In trying sudo apt-get install fftw*, you see (currently) the following: fftw2 fftw-dev fftw-docs

No good. So, the procedure is to build FFTW3 from source (which is just as easy as installing from .deb or .rpm files if you installed everything I mentioned above). That said, your attempts to build FFTW3 and build GROMACS may have run into several errors because of how you built FFTW3. Beginning with your extracting and prep for make:

user@PROTOTYPE:~/Downloads$ tar xvf fftw-3.3.4.tar 
user@PROTOTYPE:~/Downloads$ cd fftw-3.3.4/

Any of the combinations below produce the same error:

user@PROTOTYPE:~/Downloads/fftw-3.3.4$ ./configure 
user@PROTOTYPE:~/Downloads/fftw-3.3.4$ ./configure -enable-shared=yes
user@PROTOTYPE:~/Downloads/fftw-3.3.4$ ./configure --enable-threads --enable-float

checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes

config.status: executing depfiles commands
config.status: executing libtool commands

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=OFF
user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=OFF -DFFTWF_LIBRARY='/usr/local/lib/libfftw3.a'

— The C compiler identification is GNU 4.8.2
— The CXX compiler identification is GNU 4.8.2
— Check for working C compiler: /usr/bin/cc

— Performing Test PTHREAD_SETAFFINITY
— Performing Test PTHREAD_SETAFFINITY – Success
— Could NOT find Boost
Boost >= 1.44 not found. Using minimal internal version. This may cause trouble if you plan on compiling/linking other software that uses Boost against Gromacs.
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so – found

— checking for module ‘fftw3f’
— package ‘fftw3f’ not found
— pkg-config could not detect fftw3f, trying generic detection
Could not find fftw3f library named libfftw3f, please specify its location in CMAKE_PREFIX_PATH or FFTWF_LIBRARY by hand (e.g. -DFFTWF_LIBRARY=’/path/to/libfftw3f.so’)
CMake Error at cmake/gmxManageFFTLibraries.cmake:76 (MESSAGE):
Cannot find FFTW 3 (with correct precision – libfftw3f for mixed-precision
GROMACS or libfftw3 for double-precision GROMACS). Either choose the right
precision, choose another FFT(W) library (-DGMX_FFT_LIBRARY), enable the
advanced option to let GROMACS build FFTW 3 for you
(-GMX_BUILD_OWN_FFTW=ON), or use the really slow GROMACS built-in fftpack
library (-DGMX_FFT_LIBRARY=fftpack).
Call Stack (most recent call first):
CMakeLists.txt:733 (include)

— Configuring incomplete, errors occurred!
See also “/home/user/Downloads/gromacs-5.0.1/CMakeFiles/CMakeOutput.log”.
See also “/home/user/Downloads/gromacs-5.0.1/CMakeFiles/CMakeError.log”.

Including –enable-shared takes care of this error and gets you to a successful GROMACS build.

user@PROTOTYPE:~/Downloads/fftw-3.3.4$ ./configure --enable-threads --enable-float --enable-shared

— The C compiler identification is GNU 4.8.2
— The CXX compiler identification is GNU 4.8.2
— Check for working C compiler: /usr/bin/cc

— Performing Test PTHREAD_SETAFFINITY
— Performing Test PTHREAD_SETAFFINITY – Success
— Could NOT find Boost
Boost >= 1.44 not found. Using minimal internal version. This may cause trouble if you plan on compiling/linking other software that uses Boost against Gromacs.
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so – found

— checking for module ‘fftw3f’
— found fftw3f, version 3.3.4
— Looking for fftwf_plan_r2r_1d in /usr/local/lib/libfftw3f.so
— Looking for fftwf_plan_r2r_1d in /usr/local/lib/libfftw3f.so – found
— Looking for fftwf_have_simd_avx in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_simd_avx in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_simd_sse2 in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_simd_sse2 in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_simd_avx in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_simd_avx in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_simd_altivec in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_simd_altivec in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_simd_neon in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_simd_neon in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_sse2 in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_sse2 in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_sse in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_sse in /usr/local/lib/libfftw3f.so – not found
— Looking for fftwf_have_altivec in /usr/local/lib/libfftw3f.so
— Looking for fftwf_have_altivec in /usr/local/lib/libfftw3f.so – not found
CMake Warning at cmake/gmxManageFFTLibraries.cmake:89 (message):
The fftw library found is compiled without SIMD support, which makes it
slow. Consider recompiling it or contact your admin
Call Stack (most recent call first):
CMakeLists.txt:733 (include)

— Using external FFT library – FFTW3
— Looking for sgemm_

— Configuring done
— Generating done
— Build files have been written to: /home/user/Downloads/gromacs-5.0.1

And out of a first-pass GROMACS build…

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=OFF

Scanning dependencies of target libgromacs
[0%] Building C object src/gromacs/CMakeFiles/libgromacs.dir/__/external/tng_io/src/compression/bwlzh.c.o
[0%] Building C object src/gromacs/CMakeFiles/libgromacs.dir/__/external/tng_io/src/compression/bwt.c.o

[100%] Building CXX object src/programs/CMakeFiles/gmx.dir/legacymodules.cpp.o
Linking CXX executable ../../bin/gmx
[100%] Built target gmx

5. But You Let cmake Build FFTW3. So, Continuing The Build Process

With all of the dependencies above installed, the one note I wanted to address was that for Boost:


— Performing Test PTHREAD_SETAFFINITY – Success
— Could NOT find Boost
Boost >= 1.44 not found. Using minimal internal version. This may cause trouble if you plan on compiling/linking other software that uses Boost against Gromacs.
— Looking for zlibVersion in /usr/lib/x86_64-linux-gnu/libz.so

It certainly isn’t a major issue, but I wanted to try to get an warning-free build. Installing Boost 1.56 produced the following negative result:

user@PROTOTYPE:~/Downloads/boost_1_56_0$ ./bootstrap.sh 

Building Boost.Build engine with toolset gcc… tools/build/src/engine/bin.linuxx86_64/b2
Detecting Python version… 2.7
Detecting Python root… /usr
Unicode/ICU support for Boost.Regex?… not found.
Generating Boost.Build configuration in project-config.jam…

Bootstrapping is done. To build, run:

./b2

To adjust configuration, edit ‘project-config.jam’.
Further information:

– Command line help:
./b2 –help

– Getting started guide:

http://www.boost.org/more/getting_started/unix-variants.html

– Boost.Build documentation:

http://www.boost.org/boost-build2/doc/html/index.html

user@PROTOTYPE:~/Downloads/boost_1_56_0$ sudo ./b2 install

Performing configuration checks

– 32-bit : no (cached)
– 64-bit : yes (cached)
– arm : no (cached)

…failed updating 58 targets…
…skipped 12 targets…
…updated 11322 targets…

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=ON -DGMX_DOUBLE=OFF
user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ make

[0%] Building NVCC (Device) object src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_copyrite_gpu.cu.o
[0%] Building NVCC (Device) object src/gromacs/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_pmalloc_cuda.cu.o

[7%] Building CXX object src/gromacs/CMakeFiles/libgromacs.dir/commandline/cmdlinehelpwriter.cpp.o
In file included from /home/user/Downloads/gromacs-5.0.1/src/gromacs/options/basicoptions.h:52:0,
from /home/user/Downloads/gromacs-5.0.1/src/gromacs/commandline/cmdlinehelpwriter.cpp:55:
/home/user/Downloads/gromacs-5.0.1/src/gromacs/options/../utility/gmxassert.h:47:57: fatal error: boost/exception/detail/attribute_noreturn.hpp: No such file or directory
#include
^
compilation terminated.
make[2]: *** [src/gromacs/CMakeFiles/libgromacs.dir/commandline/cmdlinehelpwriter.cpp.o] Error 1
make[1]: *** [src/gromacs/CMakeFiles/libgromacs.dir/all] Error 2
make: *** [all] Error 2

Sadly, the solution is to then include -DGMX_EXTERNAL_BOOST=off and stick with the internal boost, which then “makes” just fine. One page references the use of -DGMX_INTERNAL_BOOST=on, but that produced the following:

CMake Warning:
Manually-specified variables were not used by the project:

GMX_INTERNAL_BOOST

— Build files have been written to: /home/user/Downloads/gromacs-5.0.1

There’s more on this issue at: gerrit.gromacs.org/#/c/1232/ and t24960.science-biology-gromacs-development.biotalk.us/compiling-boost-problem-and-error-with-icc-t24960.html, but I’ve opted not to worry about it.

So, with Boost installed, I simply ignore it (and have not installed Boost on my RealBox).

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=ON -DGMX_EXTERNAL_BOOST=off

6. Finishing Step If All Above Goes Well: CUDA-Based GROMACS Build

If everything else above has gone smoothly (and if you ignored the Boost install. If you didn’t, remember to add -DGMX_EXTERNAL_BOOST=off to the cmake below), you should be able to cleanly run a cmake for a GPU version of GROMACS (below, with the final result to be placed into /opt/gromacs_gpu. You then specify the $PATH after and run with it).

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ cmake -DGMX_GPU=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs_gpu -DGMX_BUILD_OWN_FFTW=ON

— The C compiler identification is GNU 4.8.2
— The CXX compiler identification is GNU 4.8.2

— Generating done
— Build files have been written to: /home/damianallis/Downloads/gromacs-5.0.1

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ make

The make starts with the FFTW3 download and build…

Scanning dependencies of target fftwBuild
[ 0%] Performing pre-download step for ‘fftwBuild’
— downloading…
src=’http://www.fftw.org/fftw-3.3.3.tar.gz’
dest=’/home/damianallis/Downloads/gromacs-5.0.1/src/contrib/fftw/fftw.tar.gz’
— [download 0% complete]

[100%] Building CXX object src/programs/CMakeFiles/gmx.dir/legacymodules.cpp.o
Linking CXX executable ../../bin/gmx
[100%] Built target gmx

Finally, your (sudo) make install places everything into /opt/gromacs_gpu.

user@PROTOTYPE:~/Downloads/gromacs-5.0.1$ sudo make install

— The GROMACS-managed build of FFTW 3 will configure with the following optimizations: –enable-sse2
— Configuring done
— Generating done
— Build files have been written to: /home/damianallis/Downloads/gromacs-5.0.1
[1%] Built target fftwBuild

[100%] Building CXX object src/programs/CMakeFiles/gmx.dir/legacymodules.cpp.o
Linking CXX executable ../../bin/gmx
[100%] Built target gmx

GROMACS 4.5.5, OpenMPI 1.6, And FFTW 3.3.2 Compilation Under Mountain Lion (OSX 10.8) With XCode (And A Little Help From Homebrew)

Tuesday, August 28th, 2012

Minus a few glitches easily fixed with the right software, this build wasn’t bad at all (and thanks to Adam Lindsay for the title catch).

Now sitting in front of a new Core i7 MacBook Pro, one of the first compilations I wanted to have finished for new projects was GROMACS 4.5.5. As my procedure for compiling GROMACS 3.3.3 had been a highly-traveled page, I wanted to provide a brief summary of my successful 4.5.5 compilation.

A Few Piece Of Info

1. XCode

This used to be disc-download and install, now it’s available as a free download from the App Store (1.57 GB download, so plan to do something else while you wait for the download).

2. Homebrew

Having Homebrew installed in Mountain Lion made the installation of FFTW easy and OpenMPI trivial once gfortran was equally trivially installed. Therefore, to make your life easier, I can’t recommend a Homebrew installation enough. For additional install tweaks, I followed the following page: gist.github.com/1860902

Installation Procedure

1. Download gromacs 4.5.5

…and place it in your home folder (will go to Downloads most likely, drag it to your home folder for ease of building).

2. Extract into your home holder

…with a double-click, making ~/gromacs-4.5.5.

3. brew install fftw

With the install of Homebrew, you’ll simply run the following from a terminal window and produce the following output:

brew install fftw

==> Downloading http://www.fftw.org/fftw-3.3.2.tar.gz
######################################################################## 100.0%
==> ./configure --enable-single --enable-sse --enable-shared --disable-debug 
--prefix=/usr/local/Cellar/fftw/3.3.2 --enable-threads --disable-fortran
==> make install
==> make clean
==> ./configure --enable-sse2 --enable-shared --disable-debug 
--prefix=/usr/local/Cellar/fftw/3.3.2 --enable-threads --disable-fortran
==> make install
==> make clean
==> ./configure --enable-long-double --enable-shared --disable-debug 
--prefix=/usr/local/Cellar/fftw/3.3.2 --enable-threads --disable-fortran
==> make install
/usr/local/Cellar/fftw/3.3.2: 34 files, 13M, built in 2.7 minutes

4. brew install gfortran

If you don’t install gfortran FIRST and try to install OpenMPI, you’ll get the following error in Homebrew:

==> Downloading http://www.open-mpi.org/software/ompi/v1.6/downloads/openmpi-1.6.tar.bz2
######################################################################## 100.0%
Error: This formula requires a fortran compiler, but we could not find one by
looking at the FC environment variable or searching your PATH for `gfortran`.
Please take one of the following actions:

  - Decide to use the build of gfortran 4.2.x provided by Homebrew using
        `brew install gfortran`

  - Choose another Fortran compiler by setting the FC environment variable:
        export FC=/path/to/some/fortran/compiler
    Using an alternative compiler may produce more efficient code, but we will
    not be able to provide support for build errors.

So don’t. Installing gfortran will produce the following:

brew install gfortran

==> Downloading http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg
######################################################################## 100.0%
==> Installing gfortran 4.2.4 for XCode 4.2 (build 5666) or higher
==> Caveats
Brews that require a Fortran compiler should not use:
  depends_on 'gfortran'

The preferred method of declaring Fortran support is to use:
  def install
    ...
    ENV.fortran
    ...
  end

==> Summary
/usr/local/Cellar/gfortran/4.2.4-5666.3: 86 files, 72M, built in 39 seconds

5. brew install openmpi

This is what allows you to use all cores on your machine and is not in the default XCode install.

brew install openmpi

==> Downloading http://www.open-mpi.org/software/ompi/v1.6/downloads/openmpi-1.6.tar.bz2
Already downloaded: /Library/Caches/Homebrew/open-mpi-1.6.tar.bz2
==> Using Homebrew-provided fortran compiler.
This may be changed by setting the FC environment variable.

==> ./configure --prefix=/usr/local/Cellar/open-mpi/1.6 --enable-ipv6
==> make all
==> make install
/usr/local/Cellar/open-mpi/1.6: 674 files, 21M, built in 5.9 minutes

6. cd gromacs-4.5.5

7. ./configure –enable-float –enable-mpi

You’ll produce output such as found in: 2012august29_gromacs455_configure.txt

You’ll also get two odd errors at the end of the ./configure run that do not affect the rest of the procedure:

./configure --enable-float --enable-mpi

...
./configure: line 29242: sort: No such file or directory
./configure: line 29239: sed: No such file or directory

So ignore them.

NOTE: If you’ve been going by my 3.3.3 procedure and used…

./configure --enable-mpi --enable-double

You’ll get the following error when you try to run make:

Making all in include
Making all in .
make[2]: Nothing to be done for `all-am'.
Making all in types
make[2]: Nothing to be done for `all'.

...

/bin/sh ../../libtool --tag=CC   --mode=compile mpicc -DHAVE_CONFIG_H -I. -I../../src -I/usr/include/libxml2 -I../../include -DGMXLIBDIR=\"/usr/local/gromacs/share/top\"   -O3 -fomit-frame-pointer -finline-functions -Wall -Wno-unused -msse2 -funroll-all-loops -std=gnu99 -MT genborn_sse2_double.lo -MD -MP -MF .deps/genborn_sse2_double.Tpo -c -o genborn_sse2_double.lo genborn_sse2_double.c
 mpicc -DHAVE_CONFIG_H -I. -I../../src -I/usr/include/libxml2 -I../../include -DGMXLIBDIR=\"/usr/local/gromacs/share/top\" -O3 -fomit-frame-pointer -finline-functions -Wall -Wno-unused -msse2 -funroll-all-loops -std=gnu99 -MT genborn_sse2_double.lo -MD -MP -MF .deps/genborn_sse2_double.Tpo -c genborn_sse2_double.c  -fno-common -DPIC -o .libs/genborn_sse2_double.o
genborn_sse2_double.c:931: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [genborn_sse2_double.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

So don’t do that, either. The proper flag is the enable-float.

8. make

This will produce the output available for download at: 2012august29_gromacs455_make.txt

9. make install

This will produce the output available for download at: 2012august29_gromacs455_make_install.txt

10. make links

This will produce the short piece of output reproduced below.

cd /usr/local/gromacs/bin && programs=`ls` && cd /usr/local/bin && \
	for i in $programs; do \
	   (test ! -f $i && ln -s /usr/local/gromacs/bin/$i . ; exit 0); \
	done

And with that, you should be able to run all programs from a terminal window.

Examining The Effects Of Vitamin B12 Conjugation On The Biological Activity Of Insulin: A Molecular Dynamic And In Vivo Oral Uptake Investigation

Thursday, March 22nd, 2012

Published in MedChemComm (direct link: xlink.rsc.org/?doi=C2MD20040F). And Happy Belated New Year. After the methodological work that went into the Molecular Biosystems paper, this was a remarkably simple molecular dynamics study of the changes to vitamin B12 binding in transcobalamin II (TCII) with the B12 conjugated to the first amino acid side chain in the B-Chain of insulin. The structure of the B12-insulin conjugate is shown below in a molecular dynamics snapshot, which reveals that the binding of B12 to its TCII transport protein is negligibly affected.

And apparently the experiments went well, too. Cover hopefully to follow.

Susan Clardy-James, Damian G. Allis, Timothy J. Fairchild and Robert P. Doyle

Abstract: The practical use of the vitamin B12 uptake pathway to orally deliver peptides and proteins is much debated. To understand the full potential of the pathway however, a deeper understanding of the impact B12 conjugation has on peptides and proteins is needed. We previously reported an orally active B12 based insulin conjugate attached at LysB29 with hypoglycaemic properties in STZ diabetic rats. We are exploring an alternative attachment for B12 on insulin in an attempt to determine the effect B12 has on the protein biological activity. We describe herein the synthesis, characterization, and purification of a new B12-insulin conjugate, which is attached between the B12 ribose hydroxyl group and insulin PheB1. The hypoglycemic properties resulting from oral administration (gavage) of such a conjugate in STZ diabetic rats was similar to that noted in a conjugate covalently linked at insulin LysB2911, demonstrating the availability of both position on insulin for B12 attachment. A possible rationale for this result is put forward from MD simulations. We also conclude that there is a dose dependent response that can be observed for B12-insulin conjugates, with doses of conjugate greater than 10-9 M necessary to observe even low levels of glucose drop.

Vitamin B12 In Drug Delivery: Breaking Through The Barriers To A B12 Bioconjugate Pharmaceutical

Friday, December 10th, 2010

In press in Expert Opinion On Drug Delivery (DOI:10.1517/17425247.2011.539200). The theory section (the only part I can properly speak to) builds on the discussion section of the full theory paper in Molecular Biosystems from earlier this year, providing an outlet for some of the more speculative design possibilities for trinary B12 bioconjugate design. Given that (1) there are mechanisms for cleavage at both of the proposed positions and (2) the molecular dynamics work indicates that, at least, TCII (transcobalamin II) can easily accommodate a bi-functionalized cobalamin, the A-B12-C design possibility is probably the most interesting long-term idea to come out of the computational side of the B12-insulin bioconjugate study (or so I argue).

Having “B12″ and “cobalamin” in a blog post guarantees a bunch of useless moderation-necessary comments from vita-spam sites.

Susan M. Clardy, Damian G. Allis, Timothy J. Fairchild & Robert P. Doyle

Syracuse University, Syracuse, Department of Chemistry, NY 13244-4100, USA

Importance of the field: Vitamin B12 (B12) is a rare and vital micronutrient for which mammals have developed a complex and highly efficient dietary uptake system. This uptake pathway consists of a series of proteins and receptors, and has been utilized to deliver several bioactive and/or imaging molecules from 99mTc to insulin.

Areas covered in this review: The current field of B12-based drug delivery is reviewed, including recent highlights surrounding the very pathway itself.

What the reader will gain: Despite over 30 years of work, no B12-based drug delivery conjugate has reached the market-place, hampered by issues such as limited uptake capacity, gastrointestinal degradation of the conjugate or high background uptake by healthy tissues. Variability in dose response among individuals, especially across ageing populations and slow oral uptake (several hours), has also slowed development and interest.

Take home message: This review is intended to stress again the great potential, as yet not fully realized, for B12-based therapeutics, tumor imaging and oral drug delivery. This review discusses recent reports that demonstrate that the issues noted above can be overcome and need not be seen as negating the great potential of B12 in the drug delivery field.

The Binding Of Vitamin B12 To Transcobalamin(II); Structural Considerations For Bioconjugate Design – A Molecular Dynamics Study

Thursday, July 22nd, 2010

In press, in the journal Molecular Biosystems. A first official foray into molecular dynamics-only (MD-only) computational work and I am pleased to report that the computational results not only make sense with respect to the experimental results, they also indicate a possible new way to use vitamin B12 for the oral delivery of bio-active molecules more complicated than the binary bioconjugates considered to date.

The Interesting Result

The conclusion from the previous study was that the insulin B Chain (figure below) acts as a tether to separate the structured region of insulin (the region with the largest inflexible steric bulk, see below) from the region of the transcobalamin II (TCII) that bind vitamin B12. It was then determined that the approach employed for the B12-insulin bioconjugate, simply linking one biomolecule onto another with known binding and transport properties (this is a common theme in all bioconjugate design), worked because the last 10 residues in the insulin B Chain (B22 to B30) are flexible in solution (they, in fact, cover the insulin binding region in the crystal form, then uncover this region in the biologically active form).

As a general procedure for B12 bioconjugate design, one of the key requirements for a functional product is a tether length that provides sufficient separation between B12 and any molecular structure large enough to affect B12 binding within its transport proteins (makes sense, as a tethered structure that does not enable B12 binding in its transport proteins will find the B12 bioconjugate delivered to the gut where acids and digestive enzymes will hide the failed binding). This leads to the question, “How long must a tether be to meet this rather general criterion?” This is, partly, the correct question, as the retention of B12 binding within its transport proteins is a function of both proper tether length and [transport protein]-[“other molecule”] interaction (in this first case, “other molecule” = insulin).

Saving the exhaustive analysis for the paper, this new study used this flexible region of human insulin (that is, B22 to B30, with the B12 linkage occurring on the B29 lysine side chain) as a proxy for any arbitrary tether, then used MD simulations to consider how the flexibility of this tether might lead to changes in B12 binding within its TCII pocket (the transport protein for which we have the best crystal structure). The result of these simulations was the identification of the side chain of lysine itself being just long enough to separate the B Chain tether region from the TCII protein surface. This does not mean that lysine will always serve as a perfect linkage. This means that, if the tether structure is effectively non-interacting with TCII (so not sterically demanding by itself), the lysine side chain is long enough to span the solvent-accessible hole produced by the encapsulation of B12 in (in this case) TCII.

The result is a design constraint when using lysine that is quite fortuitous! If the target peptide (insulin or whatnot) has a surface-accessible lysine side chain within a region that is flexible in solution, some simple amide chemistry may produce a viable B12 bioconjugate for delivering that peptide orally (thereby avoiding complete peptide degradation in the G.I. tract).

The More Interesting Result

Buried deep within the bottom of the Discussion section. If you watch the dynamics simulation of the TCII-[B12-tether] complex (shown below for a 300 K 50 ns simulation with 1.5 fs time steps in 14,000 waters (not shown)), you see that the binding of B12 within TCII and the geometry of the encapsulation complex are strongly linked. That is, TCII (and, presumably, its cohorts in the B12 transport pathway) can be thought of as two quite rigid fragments (Red and Blue in the animation) connected by a long tether (Green) that are separated in solution but brought into contact by the binding of vitamin B12 (Gold). The B12 is a glue that holds the fragments together, and a simple tabulation of hydrogen-bonding interactions in the crystal structure reveal that the B12 has more interactions to the A and B fragments of TCII individually than A and B have with each other (which is to say, the B12-A Segment interaction and B12-B Segment interaction are stronger than the A-B Segment interaction). From a biological perspective, this should make perfect sense. B12 is a large, extremely important biomolecule that, since we do not make it ourselves, is to be captured and transported as effectively as possible. The best way to bind this molecule is not to wait for it to burrow into a binding pocket, but rather to encapsulate it in a “clam shell” maneuver that provides “maximum embedding.” The tether between the A and B Segments technically would not have to be present if the A and B fragments were present in large quantities (although, as you might expect, the A-B tether does considerably reduce the time to complete encapsulation by forcing these fragments within close proximity).

According to the crystal structure, the B12 is entirely embedded within TCII, with only the solvent-accessible hole at the 5′-ribose position readily accessible for bioconjugate formation. If the overall structure were as rigid as a crystal structure might lead one to believe, functionalization at the cobalt position in the corrin ring would be out of the question.

As I just stated that such a binding mode would otherwise be unlikely, you can guess that there are B12 bioconjugates linked at the cobalt ring that are bio-active.

If you watch the dynamics simulation of the TCII-[B12-tether] complex, you see that the clam shell binding mode of TCII is one with a “loose hinge.” This loose hinge is really a result of the flexibility of the two protein fragments (typical protein motion) and flexibility in the short propionamide side chains of vitamin B12 that provide a bit of “spring” in the complete complex. In effect, the flexibility within the structure provides a means for cobalt to be coordinated to something without loss of B12 binding provided that the tether linking the cobalt and the “other” molecule is small enough that it does not require a large change in the A-B binding arrangement (that is, does not affect B12-A and B12-B binding).

And Then There Were Three…

The expectation/prediction/untested hypothesis is that vitamin B12 may be able to happily accommodate two additional molecules at the 5’-ribose and cobalt positions (properly designed) that then provide for the transport of two molecules and/or the delivery of three molecules (one being vitamin B12). This opens the door to a wealth of possibilities, from trinary delivery to combined drug delivery + radiopharma characterization. This is the possibility I’m most interested in pursuing in the next rounds of calculations, with the theory (presumably) providing a very good initial guess about the ideal tether designs to use with B12 for enabling delivery and bio-activity.

And Now For The Hard Work

Stepping back from the theoretical analysis for a moment, the most difficult obstacles to overcome in this study were the generation AND incorporation of force field parameters for vitamin B12 and a B12-Lysine mini-bioconjugate into GROMACS, a problem that I’ve addressed only in passing in several previous posts. What I won’t do in this post is explain the procedure (a single blog post will not do the procedure justice given the complexity of force field parameter generation). What I will do is provide the files for the topology for these systems and a short list of the modifications one needs to make in order to get these systems working. For additional reference, the same topology files are provided in the Supplemental Material for the paper (so, if you find yourself using these, obviously cite the paper and not my humble blog).

Files And Contents:

These are not files to be placed in a single directory, but are segments of file that are going to be placed directly into pre-existing topology files. This is not the best way to do it but is the procedure I began with and will not be changing without finding a very simple tutorial on how-to (which, if you have, I’d be happy to read).

The contents of the topology file (which I assume for you will be ffG53a6 but should work generally) are provided below:

ffG53a6_B12_BCN_LYB_LCB_topology.txt

The topology specifications for vitamin B12 (nothing bound to the cobalt in the corrin ring), cyanocobalamin (CN-B12, with a cyanide bound to the cobalt), B12 with a lysine residue attached to the 5’-ribose hydroxyl position (the tether linkage for the GROMACS prep programs), and CN-B12 with a lysine residue attached to the 5’-ribose hydroxyl position.

I am assuming that you’re using the ffG53a6 force field, meaning you add the topology sets to the bottom of the ffG53a6.rtp file.

GROMACS Modifications:

GROMACS force field and topology files must be modified slightly in order to read the topologies generated above and, depending on where you got the B12 structure, add/correct the hydrogen atoms in the B12 molecule.

In a typical UNIX/Linux installation (which I have provided compilation instructions for in a previous post), the files to be modified can be found in /usr/local/gromacs. And, if you’re using Ubuntu like I am, you’ll need to “sudo” these modifications.

1. aminoacids.dat

If you open this file, you see a list of three- and four-letter codes in the format:

50
ABU
ACE
...
VAL
PGLU

The “50” refers to the number of codes. As we’re going to be adding the codes B12, BCN, LYB, and LCB into GROMACS, we first change 50 to 54, then just list the four codes at the bottom of the file:

54
ABU
ACE
...
VAL
PGLU
B12
BCN
LYB
LCB

You’ll note that B12 and BCN aren’t like the others, LYB is not LYS, and LCB is also nowhere to be seen. The codes in this file are STANDARD and make sure you don’t inadvertently name your inserted structure one of the structures in the list.

2. ffG53a6.hdb

I specifically used the ffG53a6 force field for the TCII-B12 work, meaning I only made modifications to these force field files. The ffG53a6.hdb file is responsible for adding/correcting hydrogen atoms in your structure (just because the crystallographers do not see them does not mean they aren’t there) and contains hydrogen-beautification information for all of the three/four-letter codes recognized in aminoacids.dat. The content below is the hydrogen-correcting data for the B12, BCN, LYB, and LCB structures. Simply paste this into the bottom of the ffG53a6.hdb file.

B12     19
1    2    HAO    N62    C61    O63
1    2    HAN    N62    C61    C60
1    2    HAM    N52    C50    O51
1    2    HAL    N52    C50    C49
1    2    HAK    N45    C43    O44
1    2    HAJ    N45    C43    C42
1    2    HAI    N40    C38    O39
1    2    HAH    N40    C38    C37
1    2    HAE    N29    C27    O28
1    2    HAD    N29    C27    C26
1    2    HAG    N33    C32    O34
1    2    HAF    N33    C32    C31
1    2    HAA    O7R    C2R    C1R
1    2    HAB    O8R    C5R    C4R
1    2    HAC    N59    C57    O58
1    1    H2B    C2B    N1B    N3B 
1    1    H4B    C4B    C5B    C9B
1    1    H7B    C7B    C8B    C6B
1    1    H10    C10    C9     C11
LYB     20       
1    1    H      N      -C     CA
1    4    HZ1    NZ     CE     CD
1    2    HAO    N62    C61    O63
1    2    HAN    N62    C61    C60
1    2    HAM    N52    C50    O51
1    2    HAL    N52    C50    C49
1    2    HAK    N45    C43    O44
1    2    HAJ    N45    C43    C42
1    2    HAI    N40    C38    O39
1    2    HAH    N40    C38    C37
1    2    HAE    N29    C27    O28
1    2    HAD    N29    C27    C26
1    2    HAG    N33    C32    O34
1    2    HAF    N33    C32    C31
1    2    HAA    O7R    C2R    C1R
1    2    HAC    N59    C57    O58
1    1    H2B    C2B    N1B    N3B
1    1    H4B    C4B    C5B    C9B
1    1    H7B    C7B    C8B    C6B
1    1    H10    C10    C9     C11
BCN     19
1    2    HAO    N62    C61    O63
1    2    HAN    N62    C61    C60
1    2    HAM    N52    C50    O51
1    2    HAL    N52    C50    C49
1    2    HAK    N45    C43    O44
1    2    HAJ    N45    C43    C42
1    2    HAI    N40    C38    O39
1    2    HAH    N40    C38    C37
1    2    HAE    N29    C27    O28
1    2    HAD    N29    C27    C26
1    2    HAG    N33    C32    O34
1    2    HAF    N33    C32    C31
1    2    HAA    O7R    C2R    C1R
1    2    HAB    O8R    C5R    C4R
1    2    HAC    N59    C57    O58
1    1    H2B    C2B    N1B    N3B 
1    1    H4B    C4B    C5B    C9B
1    1    H7B    C7B    C8B    C6B
1    1    H10    C10    C9     C11
LCB     20       
1    1    H      N      -C     CA
1    4    HZ1    NZ     CE     CD
1    2    HAO    N62    C61    O63
1    2    HAN    N62    C61    C60
1    2    HAM    N52    C50    O51
1    2    HAL    N52    C50    C49
1    2    HAK    N45    C43    O44
1    2    HAJ    N45    C43    C42
1    2    HAI    N40    C38    O39
1    2    HAH    N40    C38    C37
1    2    HAE    N29    C27    O28
1    2    HAD    N29    C27    C26
1    2    HAG    N33    C32    O34
1    2    HAF    N33    C32    C31
1    2    HAA    O7R    C2R    C1R
1    2    HAC    N59    C57    O58
1    1    H2B    C2B    N1B    N3B
1    1    H4B    C4B    C5B    C9B
1    1    H7B    C7B    C8B    C6B
1    1    H10    C10    C9     C11

As brief explanation, the three-letter code is followed by the number of Hydrogen atoms that are to be added. Each line can be read:

First Column – The number of hydrogen atoms added (so all of these entries on the far left mean “add ONE hydrogen”)

Second Column – The manner by which the hydrogen atom is to be added (this is listed in section 5.5 of the GROMACS 3.3 Manual (page 93))

Third Column – The name of the Hydrogen atom to be added

Fourth Column – The atom to which the H is going to be directly linked in the topology file

Fifth – Seventh Columns
– atoms that define how the Hydrogen is added with respect to (1) the code in Column 2 and (2) the atom to which the Hydrogen is added.

3. ffG53a6bon.itp

There are a few subtle tweaks to the force constants for a few bonds that I perform here right within the file and that proper MD people likely would scream at. I note that, when you do this, you are making changes to numbers that will affect the results if you somehow start doing heme MD simulations.

Change the gb_NN values to those provided below.

#define gb_34        0.198  0.6400e+06
; NR  -   FE    120
#define gb_4         0.1142  3.7000e+07
; C - O (CO in heme)  2220
#define gb_14       0.1340  1.1000e+07
; C  -  NR (heme)       1000
#define gb_30       0.1880  2.7200e+06
; FE  -  C (Heme)

You will note that I have not done anything to make cobalt appear in the topology or force field files. For the sake of running a simulation, Fe and Co are close enough that simply replacing CO for FE in the PDB file is sufficient. You can do the completely proper job of adding cobalt to the force field to get the mass right.

And that is the bare basics for getting a run to happen. A proper tutorial on how to generate force field parameters and topologies may be forthcoming, depending largely on interest and my ability to find time to do it.

Article citation: Damian G. Allis, Mol. BioSyst., 2010, DOI: 10.1039/c003476b

Damian G. Allis1, Timothy J. Fairchild2 and Robert P. Doyle1

1. Department of Chemistry, Syracuse University, Syracuse, NY 13244, USA
2. School of Chiropractic and Sports Science, Murdoch University, Murdoch, WA 6150, Australia

As part of ongoing research into the use of vitamin B12 (B12; cobalamin; Cbl)-based bioconjugate approaches for the oral delivery of peptides/proteins, a molecular dynamics (MD) study of the binding of a cyanocobalamin–insulin (CN–Cbl–insulin) conjugate to human transcobalamin(II) (TCII) was recently reported that provides a qualitative picture of how the human insulin protein in its open T-state geometry affects CN–Cbl binding to TCII. This initial analysis revealed that the B22–B30 segment of the insulin B-chain acts as a long tether that connects the larger combined insulin A/B region to CN–Cbl when this conjugation is performed at the CN–Cbl ribose 5-hydroxy position. The experimental support for this model of the binding interaction is provided by the consequences of the successful delivery of the CN–Cbl–insulin conjugate in the production of significantly decreased blood glucose levels in diabetic STZ-rat models. In efforts to provide a more detailed description of the (CN–Cbl)–TCII complex for modeling Cbl-based bioconjugate designs, the (CN–Cbl)–TCII system and a CN–Cbl conjugate incorporating a flexible tether composed of only the B22–B30 segment of human insulin have been examined by MD simulations. The implications of these simulations are discussed in terms of successful conjugate positioning on Cbl, especially when such sites are not apparent from the diffraction studies alone, and the possibilities, as yet not reported, for dual-tethered Cbl bioconjugates for multi-component drug delivery applications.

Obligatory

  • CNYO

  • Sol. Sys. Amb.

  • Ubuntu 4 Nano

  • NMT Review

  • N-Fact. Collab.

  • Pres. Asn. CNY

  • T R P Nanosys

  • Nano Gallery

  • nano gallery
  • Aerial Photos

    More @ flickr.com

    Syracuse Scenes

    More @ flickr.com