Why are the ligands INSIDE the protein?

Hello,
I just started contributing to the project after hearing a presentation about it at a conference. I've been looking at the graphics here and there (all my work units so far have been HIV Protease). In nearly all casese I've looked at the graphics for the compound is not in the active site but is often jammed deep inside the protein. I'm just curious if this is a rendering issue or if it's really trying to calculate how to get the compound outside of the protein core and into the active site.

I'm also surprised the RMSD comes down so far even though the compound is clearly far from home. Do the project leaders have a comment on this? I'd prefer it if the cycles I'm donating were going towards models that were making some kind of physical sense. Thanks.

Well, I don't know if the project operators saw my message or not, but the latest work units show the ligand in or at least close to the compound binding site, rather than sitting deep in the protein core making lots of clashes. Fun project.

Well, I don't know if the project operators saw my message or not, but the latest work units show the ligand in or at least close to the compound binding site, rather than sitting deep in the protein core making lots of clashes. Fun project.

Thanks for checking on that. My spot checks going forward show the inhibitors in the peptide-binding groove so whatever it was seems to have stopped. Thanks for your respose!

I'm looking at the graphics for the 1liq batch and so far all the compounds seem to burried inside the protein again (physically lodged in the core of the protein stearically clashing with tons of sidechains) and not near the substrate binding site. Is this a test to see if the program can move the compound into better position, or is it just a display issue?

I'm looking at the graphics for the 1liq batch and so far all the compounds seem to burried inside the protein again (physically lodged in the core of the protein stearically clashing with tons of sidechains) and not near the substrate binding site. Is this a test to see if the program can move the compound into better position, or is it just a display issue?

Thanks. I'll send a representative image to the e-mail addres in your sig.

Thanks. I'll send a representative image to the e-mail addres in your sig.

Thanks for working on this issue of stearic clash. I'm noticing it again for 1ohr_mod0014 work units. I'm sending a picture to the e-mail listed on the prior posts. Clearly the cyclohexyl group is physically overlapping with protein atoms, and the amide linker to the t-butyl group is crashing into protein backbone. Is this just a display error or are we really starting with compounds embedded in the protein. I can't imagine the minimizer would know how to get them back out.

We may have stumbled onto an explination for this behavior. I did some work on the screensaver and I am currently working on a project that is closely related to (works in conjunction with) it. At any rate while coding my own graphical application using the data files which represent the ligand protein structures I noticed that the world coordinates given (for the atoms) are not centered about the world origin. For example, the 1tng ligand is pretty close to the origin although slightly tilted away from it. The 1ohr ligand is shifted about 5 whole units away from the origin.

So, why is this a problem, you may ask. Well in opengl, there is of course a world coordinate space, however it's nice to group certian pieces of geometry together (atoms and bonds for instance) into their own local coordinate space. That way when you perform a translation or rotation all of these objects (atoms and bonds) move together as if they are attached. The problem is, that if you load all of the objects into their own coordinate space, and they aren't centered around the origin, but are in fact offset, then where ever you translate them to, they will be just as offset as they were before you moved them.

It's like the solar system. The solar system moves through space right, but the planets still stay offset from the sun (the origin of our solar system's local coordinate system). But to the programmer, we only have control of moving that center point, we can tell the sun where to move, but the planets will just follow it. So you can immagine that if we think the ligand is close to it's origin but it's really offset, it might look offset from where we calculated it should be.

At any rate, I will personally look into this problem. We have looked at results from the docking algorithm and have shown that the results are valid. Specifically we've loaded the world coordinate positions of the atoms of the ligand and protein and confirmed that the results of the algorithm are correct (ligand docked in the correct pocket). I am confident that there is a graphical bug related to above mentioned phenomenon. I'll be looking into providing a fix for this in the near future.

Rest assured that the bug that you are seeing is purely cosmetic and in no way relects the quality of the computation being performed. Sorry for the inconvenience.

So as I've written above, I was going to look into this bug to figure out where the problem was. I'm writing today to confirm that my initial assumption is correct. That is, the simulation's results ARE CORRECT, the graphical portion of the application simply renders them at the incorrect position. The screensaver code calculates a center of geometry and then uses this to shift the molecules to the viewable part of the screen. Unfortunately after that point the molecule (as a set of atoms) is moved around by this calculated offset. What the screensaver needs to do is treat each atom individually, or better yet, calculate the COG of the complex (the ligand docked into the protein), treating the whole structure as one entity. The latter is the solution that I will work in implementing.

So how did I prove that this was infact the problem? Well I've been working on another program which also works with displaying proteins and ligands. So I took the OP's workunit, and regenerated it using the 1t7k complex with the same random seed the OP had. As the OP had shown, this generated what looked like steric clashes in the complex (in the graphical application). So I took the generated ligand and protein description files, which were used in the graphical app, and I loaded them into my own application. Below I show an image comparing both. Notice that the original graphical application (right) shows a gaping docking pocket with the ligand clashing inside the protein. On the left, you can see my graphical application shows that, using the same files, the ligand nestles into the docking pocket where it should be.



So once again, I'll be working on correcting this bug in our google code repository using the method described above. The scientific code has been verified as correct so users shouldn't worry wasting computation on invalid results. Just be aware that there is a benign shifting bug in the graphical application. I'd also like to thank our vigilant users, particularly the OP anthonmg. We'll keep you posted on the fix. Thanks again for all your help.

Hello,
I just started contributing to the project after hearing a presentation about it at a conference. I've been looking at the graphics here and there (all my work units so far have been HIV Protease). In nearly all casese I've looked at the graphics for the compound is not in the active site but is often jammed deep inside the protein. I'm just curious if this is a rendering issue or if it's really trying to calculate how to get the compound outside of the protein core and into the active site.

I'm also surprised the RMSD comes down so far even though the compound is clearly far from home. Do the project leaders have a comment on this? I'd prefer it if the cycles I'm donating were going towards models that were making some kind of physical sense. Thanks.