Calculating Shieldings for Proteins

I'm just going to show some recent work on extending the Polarizable Embedding from being a focused QM/MM model into an approach to generate parameters for entire proteins or DNA. Here is a snapshot of the human protein GB3 (PDB: 2OED) with the central QM-fragment we are interested in - here LYS4 - shown in vdw-spheres. Also in the QM-region are neighbouring residues and stuff (side-chains and water) that binds to the central fragment of interest) all highlighted in cyan in sticks. The rest of the protein along with a lot of water is the MM-region. Only the protein is shown in a classical cartoon rendering.

Enjoy

FragIt has a better look!

Active development with FragIt is still going strong as I work my way through interfacing it with other software that we are building in-house to allow you to run these high-quality QM/MM calculations with relative ease.

I've just added a visually more pleasing color scheme to the development version which you can see in the image below

The old colorscheme is to the left and the new is to the right.

it just became a lot cooler to visually inspect your molecule of interest.

Release of FragIt 1.2

After a ferocious development spree, I am proud to announce the release of FragIt 1.2.

Under the hood, it has primarily been reworking some of the finer details of the API to allow for better integration with programs wishing to use it.

Directly from the release-notes:

This release provides Molcular Fragmentation with Conjugate Caps (MFCC) support through FragIt. Currently, it dumps all capped fragments and all caps as separate .xyz files so you can process them further on in the quantum chemistry code of your choice. You can access it through the writer = XYZ-MFCC option in the [fragmentation] group.
This release also includes some updated API for better integration with other codes that wants to interface with FragIt.

FragAway!

What is it with this linear scaling stuff anyway?

Enormous amounts of research time has gone into researching computational methods that are linear scaling with respect to the system size. That is, double the size of your system and you only double the computation time. If just all methods were as such, the queue on your local super computer cluster would be easier to guess when computers were available instead of seeing a wall of 200+ hours of jobs just sitting there because people don't give a crap.

Inspired by +Jan Jensen and a recent blog post of his (which I was reminded of when I wrote another blog post on the subject of many-body expansions), I set out to actually do the calculations on timings myself albeit with a different goal in mind.

2-body calculations
Even if you use the many-body expansion of the energy, I showed that the accumulated number of calculations one would need increases dramatically for large N-body. If we only focus on doing one- and two-body calculations, the effect is barely visible in the previous plot, but calculating the computational time from Jan's linear model (only do nearest neighbors) together with one where we do all pairs, we see that even at the two-body level, there is no linear scaling unless you do some approximations.

Here, I have assumed a computational scaling of $\alpha=2.8$ and uniform monomer sizes. I've assumed that a monomer calculation takes 1s and there is no overhead nor interaction at the monomer level.

Admittedly, the linear model is crude, but it shows the best scaling you could hope for by including the minimum amount of two-body calculations. In a more realistic case, you would end up somewhere between the red and the black line, but that is the subject for a future post.

This is why we need linear scaling!

3-body calculations
Just for the fun of it, here is the 3-body scaling

and I dare not think of what the time would be for the calculation without approximations for higher n-body calculations.

I think that we can all agree on that approximations must be made or else we are doomed.

We need linear scaling!


This work is licensed under a Creative Commons Attribution 3.0 Unported License.

FragIt and Metals

FragIt is a tool that helps you setup a fragment calculation, more specifically for use in the Fragment Molecular Orbital (FMO) method and its Testosterone induced cousin the Effective Fragment Molecular Orbital (EFMO) method.

Since my switch to the University of Southern Denmark, FragIt's capabilities have grown a bit. Now it supports Molecular Fragmentation with Conjugate Caps so it can dump coordinate files and you can estimate interaction energies quickly and I am trying to switch to a more flexible configuration system, but that is a topic for another post on a related blog.

However, my proudest moment regarding FragIt must have been today when I finally fixed an issue with FragIt that has been haunting me for some time. Metal ions. The problem is that FragIt uses the excellent Open Babel toolkit as its underlying work horse, but the charge models that are implemented are misbehaving when metals are present (through the Python bindings). The partial charges are not present for the metals which I guess makes sense

My solution was rather elegant:

while metals are present

• store a copy of them in a separate list
• delete them from the system
• calculate the partial charges of the system without the metal ions.

Finally, reinsert the metal ions and use their formal charge (which you are certainly most interested in) as the partial charge of the ion. From here, everything is as usual and you can do all your usual tricks with FragIt as you are used to.

The only catch is that whatever metal ions you want to include has to be last in whatever structure file you are using and I should mention that the web interface is not yet updated with this feature.

That's what conferences are for! Stay tuned for a 1.0.7 point release sometime in the near future.

btw - metal ions can be mispelled to say meta lions which I at this hour find rather amusing.

Extending FragIt for Molecular Fragmentation with Conjugate Caps

As the co-author of FragIt(web, code), a piece of software written in Python using the Open Babel API, to help setup and fragment large molecules in fragment based methods, I have to return to this (excellent) piece of software to make it work with Molecular Fragmentation with Conjugate Caps (MFCC) methods which is the approach that my new work-place has taken as their method of choice in fragment based methods. Currently, FragIt only (officially) supports the Fragment Molecular Orbital (FMO) method.

Step I of this transformation is to realize that FMO and MFCC are two very different beasts. While the theory of FMO is more hairy, the information that FMO needs to run is vastly less than MFCC. In FMO, you specify pairs of atoms between which you wish to fragment and then everything goes along nicely whereas in MFCC you build fragments, attach caps and build extra fragments from those caps (called conjugate caps). The latter is very tough to do generally which is the approach and idea of FragIt in the first place: Mostly because getting the correct SMARTS you need is very cumbersome. As with the previous approach of FragIt, I'll make it work for proteins by selecting the appropriate SMARTS and program it in such a way that extensions to other systems would be straight-forward by simply figuring out additional patterns.

Right now my approach is to build “capping”-SMARTS that select atoms around places of fragmentation and build those caps in Open Babel. Non-trivial task is non-trivial I must admit.

Stay tuned as I explore the SMARTS and code needed to accomplish this.