1 / 36

ProtoMS

ProtoMS. Past, Present and Future. The Past…. Fortran 77 program developed to help me complete my PhD. Design goals; Calculate protein/ligand relative binding free energies Allow easy implementation of new, related science Be fast. ProtoMC 1.0. ProtoMC 1.0 achieved these goals

gisela
Download Presentation

ProtoMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ProtoMS Past, Present and Future

  2. The Past… • Fortran 77 program developed to help me complete my PhD. • Design goals; • Calculate protein/ligand relative binding free energies • Allow easy implementation of new, related science • Be fast

  3. ProtoMC 1.0 • ProtoMC 1.0 achieved these goals • Allowed me to complete my PhD • Allowed me to develop and implement new science • Allowed me to run protein/ligand simulations 10-12 times faster than with MCPRO

  4. The Present… • Final stage of Woodman project allowed ProtoMC to be further developed • More ambitious design goals; • Be usable by other researchers • Be robust and reliable • Be feature-complete • Act as a base for the development of new science

  5. ProtoMS 2.0 • ProtoMS 2.0 achieved most of these goals • User manual and improved interface allowed the code to be taken by other users • Testing and wider use demonstrated code to be robust and reliable (though not totally bug free!) • Code was taken as the base for several other’s work, incl. Julien

  6. ProtoMS 2.1 • With the cooperation of Julien, ProtoMS 2.1 fully achieves its goals • Code is pretty feature complete, bugs have been squashed, it is now a pretty solid little program that knows its job and does it well! • Provides the foundations on which other group members can build; • Julien, Seb, Ben, Juan, Caterina, Justine

  7. The Future… • Julien has taken over the development tree with the group. He is managing the different branches of the code within the group. • Depending on the position of Astex, he may merge his work into ProtoMS 2.2 • ProtoMS 2.X provides a solid, stable base on which to build. Open license means anyone is free to take it wherever they wish • I foresee a bright future for the code used within the Essex group (and perhaps beyond!)

  8. My Future… • My plans have taken me away from the core abilities of ProtoMS • I have been working on Hybrid MC methods (mixed MC/MD), and will be working on mixed QM/MM forcefields • Neither of these methods can be implemented in ProtoMS 2.X • I foresee that over my career I will develop very radical and different ideas. ProtoMS 2.X cannot grow to accommodate these ideas

  9. Solution? • I need a new code, that can grow with my research • Design goals; • Capable of relative free energy calculations • Complicated mixed forcefields (QM/MM) • MC (incl. MTSMC) and MD capable • Extensible • Fast, robust and reliable

  10. Impossible task? • These design goals look familiar… • Despite many years of thought, and many attempts, I had never come up with a design that could meet these goals • The problem is that flexibility and speed are mutually exclusive

  11. Impossible task? • In object-orientated designs, the base object is an ‘Atom’ • This ‘Atom’ is made to be very flexible and extendable, so it can be used in all forcefields • Easy implementation, but the cost is that resolution of Atom-Atom interactions occurs within the pair-loop. This is very inefficient • Added complication of managing interactions – need to code energy of each ‘Atom’ with each other type of ‘Atom’. • How does this design model non-atom based energies, e.g. restraints, electrostatic fields, umbrella terms, QM?

  12. Christmas Present… • Solution came to me over Christmas • Make the ‘Atom’ a concrete, defined geometric class • Make the base object a ‘ForceField’ • Atoms are added to ‘ForceFields’. The total energy is the sum of the energies of each ‘ForceField’ • A single ‘Atom’ can be added to as many ‘ForceFields’ as desired, e.g. MM, restraint, QM/MM, umbrella etc.

  13. ProtoMS 3 • From this idea, ProtoMS 3 was born • Design is built on three concepts; • A solid, geometrical ‘Atom’ class • ‘CutGroups’, which group ‘Atoms’ into cutoff-based groups • ‘ForceFields’, which calculate the energy and forces of added ‘CutGroups’

  14. MM MM QM • System consists of several CutGroups… • CutGroups to represent the protein residues • CutGroup to represent the ligand • CutGroups to represent the solvent

  15. MM MM QM • System consists of three forcefields • An MM forcefield, for the purely MM interactions • A QM forcefield, for the purely QM interactions • A QM/MM forcefield for the mixed interactions

  16. MM MM QM • Design the simulation as follows; • Protein and solvent CutGroups added to MM • Ligand is added to the QM forcefield • Protein, solvent and ligand are added to QM/MM

  17. ChainRes CutGroup FlexGroup Molecule ChainMol RigidMol FlexMol CutGroup Inheritance

  18. Evolution of ProtoMS2 • The idea of a CutGroup is an evolution of the design in ProtoMS 2.X

  19. Design of the Atom Element AtomIndex Vector Atom An ‘Atom’ only knows where it is, what type of element it is, and what is its index (name and residue number). All other information is either held in the parent CutGroup (e.g. bonding), or in the ForceField (e.g. partial charge). All geometry functions that work on vectors work automatically with Atoms. Concrete class, so easy for the compiler to optimise!

  20. More ideas! • Initial implementation led to many more ideas! • CutGroup data structure optimised for speed, not for loading/editing • Separate all loading/editing into an ‘EditMol’ class • Create fast functions to convert an EditMol into any CutGroup Molecule, and then back again

  21. EditMol • All IO classes work with EditMols • This separates all energy/simulation code from IO code • EditMol has functionality to allow easy addition and deletion of atoms or residues from the molecule • This functionality is not present in any Molecule, so does not confuse the Molecule interface

  22. Core IO ForceField PDB EditMol MM CutGroup Mol2 QM AtomArray Geometry functions Trajectory Atom Volume SimSystem Thread Cartesian LocalProcessor PeriodicBox MPIProcessor Move MDMove MCMove HMCMove MTSMC

  23. Multiprocessor • A SimSystem contains a complete system to be simulated • Each SimSystem can run in its own thread (via local threads or via MPI) • Each ForceField in each SimSystem can also be split over multiple processors (as ForceFields are independent) • Each ForceField can also be parallisable • You assign processors to a SimSystem, it can then assign processors to its ForceFields

  24. Multiprocessor l=0.0 l=0.5 MM MM QM QM

  25. Non-Zmatrix based moves • Other new idea is to allow non-zmatrix based MC moves • Only need to know the connectivity of a molecule • Given connectivity, it is possible to split molecules into two parts (assuming no rings…)

  26. Move a bond…

  27. Move an angle…

  28. Move a dihedral…

  29. Implementation • I have implemented this design using a combination of C++ and Python • C++ for all of the code, exposed to a Python interface • Allows flexibility and speed • Use advanced C++ features to maximise code re-use and compile-time optimisations

  30. Current Progress • Developed since January 2005 • Around 11-15 thousand lines of code (compared to 22 thousand for ProtoMS 2.1) • Over 220 subversion commits • Implemented CutGroups, EditMol, PDB reader/writer, generic MM forcefield, bond/angle/dihedral moves… • Can calculate MM energies and compare to ProtoMS2

  31. Current Progress • Tested speed of design • Used water system (RETI test system) • New design is between 30% and 100% faster than ProtoMS 2.1! • This is despite C++ code compared to F77 • Speed-up is because C++ data-structures are optimised for the processor cache • Real test, as all the code used was ‘gold’ quality

  32. Progress Plan… • Currently working on SimSystem / ForceField / CutGroup interaction • Also working on ‘checkpoints’, a system that allows the simulation state to be quickly saved and restored • This will be used during the MC move (‘old’ and ‘new’ state), the HMC move (‘pre-MD’ and ‘post-MD’), and for the MTS-MC (‘pre-chain’ and ‘post-chain’)

  33. Core IO ForceField PDB EditMol MM CutGroup Mol2 QM AtomArray Geometry functions Trajectory Atom Volume SimSystem Thread Cartesian LocalProcessor PeriodicBox MPIProcessor Move MDMove MCMove HMCMove MTSMC

  34. Future Plans… • Want to use ProtoMS 3 when I start at Bristol at the beginning of October • Need to get bulk of coding completed by then… • Plan to spend whole of September coding • Code will not however be ready for external use for at least 18-24 months

  35. Finally… • I cannot call it ProtoMS, as this name clashes with ProtoMol, an already available code • ProtoMS was the prototype. This will be the real thing • Even before ProtoMC, I knew what I wanted to call my ‘ultimate’ simulation package • Hopefully, ProtoMS3 will become that ultimate package…

  36. Sire Simulator's Integrated Research Environment qu MC/MD Free Energy Scriptable QM/MM Model Building Multiprocessor Available 2007?

More Related