Forum Replies Created
- Posts
Hi Brady. I spent some time looking into this error today and was able to debug it using the multi-frame 2jse.pdb structure from the PDB. I’ll spare you the details, but bottom line is that the bug has been fixed with version 1.1.1, which I just pushed to the git repository: https://git.durrantlab.pitt.edu/jdurrant/pyrite
Much thanks for bringing this issue to my attention! Take care.
Hi Bharti. We recently realized that the latest version of RDKit (one of the python libraries that AutoGrow4/Gypsum-DL uses) has broken backwards compatibility. We made some updates to these programs to address the issue. I don’t know if you’re using the latest version of RDKit, but you might want to try the latest version of AutoGrow4 (4.0.1) in case this bug is affecting your run: https://git.durrantlab.pitt.edu/jdurrant/autogrow4
Take care!
Hi Brady. Very happy to hear that you’re getting good use out of BlendMol and Pyrite. I wonder if there’s something unusual in the way that PyMol saves the PDB trajectory files. Would it be possible for you to send me enough of the PDB trajectory for me to test it on my system? If I can reproduce the error, I’ll be better able to fix it. Thanks again!
Hi Bharti. Much thanks for your interest in AutoGrow. Would you mind sending me the AutoGrow parameters you’re using? That will help with debugging. We have a theory re. what’s happening, but it will be good to confirm. Take care.
Hi Bryon. Just wanted to update you re. this issue. I was surprised that MOE would output incorrect SMILES strings, so I investigated further. It turns out that my website thought some of your SMILES strings were Markdown, so it removed some of the square braces and replaced them with links! When I fixed this formatting issue, I could see that your SMILES strings were all well formed, except for one:
O=C1N(Cc2c(C#N)cccc2)C(N2C[C@H]([N+H3])CCC2)=CC(=O)N1CRDKit (which Gypsum-DL uses to load SMILES strings) doesn’t like the
[N+H3]part. When I replace that with[N+3], RDKit (and presumably Gypsum-DL) can load the SMILES string correctly.Sorry for the confusion! Take care.
Hi Byron. Much thanks for your interest in Gypsum-DL. And thanks for sending me your SMILES strings. That makes debugging much easier. Just FYI, your list contains many redundant entries. For example, this line appears three times:
O=C([O-])C@@HCCC(=O)[O-] folate derivative
But I don’t think that’s the cause of the error. Rather, it appears that some of the SMILES strings aren’t properly formatted. For example, consider this line:
S(CCN/C(/NC)=C/N+[O-])Cc1nc(CN(C)C)sc1 nizatimine (H2 blocker)
Both ChemDraw and OpenBabel gave errors when trying to process this SMILES string. I believe poorly formatted SMILES strings were also responsible for Gypsum-DL’s troubles.
But clearly Gypsum-DL shouldn’t crash entirely just because it’s given a problematic SMILES string. I updated the program so that it now throws a warning and continues on to the next string. There were also a few other updates, in case you’re interested: https://git.durrantlab.pitt.edu/jdurrant/gypsum_dl/blob/1.1.3/CHANGELOG.md
Please let me know if you continue to have this same problem with Gypsum-DL 1.1.3. Much thanks for pointing out this limitation. Take care.
Hi Ning. The pyrite tab appears in Blender’s "N Panel." With your mouse over the main viewport, just press "n". It should open up to the right, assuming you haven’t changed the default settings. One of the subpanels in that panel is labelled "Pyrite". Here’s a screenshot, in case it helps: http://durrantlab.com/apps/pyrite/files/panel_screenshot.png
Hi Alexandra. Much thanks for sending the youtube videos. That’s very helpful. Here are some suggestions:
1) Remove duplicate vertexes on both the surface and sticks. Pyride includes a "Remove Doubles" option. You can also run "Merge by Distance" in Edit Mode. You might need to run it multiple times until no further
2) You might try setting up your surface and sticks in VMD. There you can use QuickSurf (instead of Pyrite’s default Surf representation), which is a bit more ordered than Surf. You can save the VMD state as a Visualization State (*.vmd) file, which you can import with BlendMol.
I put to together a blender file that shows how I did it with a nucleic acid molecule, in case it helps. Here’s the link, which also includes a PDB trajectory and VMD state file: http://durrantlab.com/apps/pyrite/files/sticks_representation.zip
You are going to have some distortions in Blender because of the approximations it makes, but you can get pretty close to the original MD simulation. Hope this helps!
Hi Sean. Thanks for your message. I’ve never seen this error before. It appears to be a problem with RDKit, one of Gypsum-DL’s dependencies. Can you share the specific SMILES string that led to this error so I can debug? Thanks.
Hi Alexandra. Much thanks for your message. Pyrite doesn’t always handle sticks representations well. (Surface and ribbon tend to work better.) But I’ve been able to get it to work with sticks representation using Blender’s Mesh Deform Modifier. First, use BlendMol to separately import both surface- and sticks-representation meshes of the water molecule. Then use Pyrite to drive an animation of the surface mesh. Finally, use the Mesh Deform Modifier to make the surface-representation mesh drive the sticks-representation mesh. It’s a bit convoluted, but I think it should work. Hope this helps!
Thanks, Tomas. Hopefully Webina will be officially published soon. I’m quite excited about its research and educational potential. I should mention, though, that you’ll still need AutoDockTools (or OpenBabel) to convert from the PDB to PDBQT format. If you’re having problems on Catalina. perhaps OpenBabel is the way to go. Thanks again for your interest!
Hi Nicolas. If I understand you correctly, it sounds like your mesh and PDB (trajectory) coordinate systems are different. If the two coordinate systems were the same, then pressing the autofix button should have put the mesh and armature right on top of each other. Pyrite reads the trajectory coordinates right from the PDB file, so I suspect the problem is with your mesh coordinates (as exported from VMD).
Does everything work when you use the build-in test trajectory (using the "Load Test Data" button)?
One possible solution is to use the BlendMol plugin to load the VMD file directly into Blender. Blendmol automatically resets the VMD camera position before exporting the mesh, to make sure the coordinates are the same. Here is a video tutorial showing how it’s done in 2.79, but 2.80 is similar: https://durrantlab.pitt.edu/apps/blendmol/docs/VideoS4.BlendMol-Pyrite-Tutorial.mp4
Here’s the BlendMol URL: https://git.durrantlab.pitt.edu/jdurrant/blendmol
Hope this helps!
Hi Derek. Thanks again for your interest. I wanted to let you know that I just released Pyrite 1.1.0, which works on Blender 2.80 and above. Let me know if you run into any problems.
https://git.durrantlab.pitt.edu/jdurrant/pyrite
All the best.
Hi Henrik. Much thanks for your interest in BlendMol. The current version only work with Blender 2.8. I wonder if that’s the problem? If you’d like to stick with Blender 2.79, you might try the older BlendMol version posted here: https://git.durrantlab.pitt.edu/jdurrant/blendmol/tree/1_0
Best of luck.
