[Jacob Durrant]

Hi again Xiaoyu. My student pointed out that you may have encountered this error in the plotting script, not the main AutoGrow4 script. Is that right? He seems to think your Autogrow4 run may have completed after all, but that you’re just unable to plot the results. Regardless, I still recommend trying the docker container or reinstalling tkinter, since that seems to be where the dependency problem is. Take care.

[Jacob Durrant]

Hi Dan. Please forgive my delay in answering this email. I wanted to let you know that BlendMol no longer supports PyMOL (only VMD). https://git.durrantlab.pitt.edu/jdurrant/blendmol/-/blob/1_3/FAQ.md#why-cant-i-import-via-pymol-on-blender-28blendmol-13

[Jacob Durrant]

HI Xiaoyu. Much thanks for your interest in AutoGrow. You’re right to guess that this isn’t an error from AutoGrow itself, but rather one of the dependencies. Unfortunately, the error thrown is pretty cryptic! Looking over your errors, the strings "Tk_GetColor" and "Tk_InitOptions" make me think you might have a problem with your TK library installation: https://web.ics.purdue.edu/~aai/tcl8.4a4/html/TkLib/contents.htm

Have you tried using the AutoGrow4 Docker container? We created it with the goal of addressing the many OS-specific bugs like this that might arise in third-party libraries. You can find the files in the official repo: https://git.durrantlab.pitt.edu/jdurrant/autogrow4/-/tree/4.0.2/docker

Take care,

Jacob

[Jacob Durrant]

Hi Nicolas. Sorry for the delay in responding! I think you might be right about that. It would make sense that so charged a molecule would be energetically unfavorable. Take care.

[Jacob Durrant]

Hi Christian. I checked with my lab’s AutoGrow4 expert, and he said he’d need more information to be able to debug the issue. If possible, please send 1) the parameters used; 2) the version of AutoGrow4; 3) the operating system; and 4) either the source compound list and/or what the *_docking_output.txt (files in folder PDBs) read.

His guess is that either there is something wrong with the input smiles (e.g., they are misformatted somehow), or there is an OS error. I see osboxes in the pathing. Perhaps you’re using a less common flavor of Linux via Virtualbox? Could cause issues with the Vina compilation. But that’s just speculation.

Take care.

[Jacob Durrant]

Hi Nicolas. No worries about all the messages. I should start by clarifying that Gypsum-DL was trained on monoprotic compounds. Accuracy is likely less when dealing with compounds that have multiple ionization sites, especially if those sites are near each other. It’s part of the compromise between speed and accuracy that we had to strike. QM-based methods are going to be more accurate, albeit computationally expensive. (I’m sure you’re already aware of all this, but I thought it would be good to mention it for others who visit this page.)

Very impressive how thoroughly you’ve delved into the algorithm! Re. how Gypsum-DL selects the final m compounds from the mt variants, it uses RDKit to calculate the energy of the mt 3D models and then keeps the top m with the best energies. In case you’re interested, some of the relevant code is here:

https://git.durrantlab.pitt.edu/jdurrant/gypsum_dl/-/blob/1.1.6/gypsum_dl/ChemUtils.py#L115

https://git.durrantlab.pitt.edu/jdurrant/gypsum_dl/-/blob/1.1.6/gypsum_dl/ChemUtils.py#L30

It could be that your protonation state of interest is more likely to be energetically unfavorable and so is being eliminated for that reason. I believe Gypsum does compare the energies of molecules with different ionization states, as long as they come from the same input SMILES string.

Gypsum does try to eliminate molecules with very similar conformational states, though in practice I have seen some geometrically similar conformations. https://git.durrantlab.pitt.edu/jdurrant/gypsum_dl/-/blob/1.1.6/gypsum_dl/MyMol.py#L596

Hope this answer helps. Take care.

[Jacob Durrant]

Hi Federico. Thanks for your interest in Pyrite. Did you get any kind of error when you used the plugin? This sometimes happens when the mesh can’t be parented to the armature with automatic weights. It’s a limitation of Blender itself. You might try reducing the number of mesh vertexes (perhaps using Blender’s "Merge by Distance’ feature or the Decimate modifier). Fewer "bones" could also help (increasing the numbers in Pyrite’s Simplify Trajectory subpanel).

Perhaps this link could help: https://blender.stackexchange.com/questions/94633/parenting-with-automatic-weights-bone-heat-weight-failure

Take care.

[Jacob Durrant]

Hi Finn. Much thanks for your interest in AutoGrow4. I ran it by my resident AutoGrow4 expert, and he tells me that this bug was fixed in version 4.0.1: https://git.durrantlab.pitt.edu/jdurrant/autogrow4/-/blob/4.0.1/CHANGELOG.md

Are you certain you’re using the latest version?

Also, he suggest that you consider adjusting a few parameters. The max_variants_per_compound, gypsum_timeout_limit, docking_exhaustiveness parameters are all very low (all set to 1). You might consider increasing them to the defaults or higher. Take care.

[Jacob Durrant]

Sorry for my delay in responding, Yash. Very happy you were able to resolve the problem. Much thanks, too, for posting your solution to help others. Take care.

[Jacob Durrant]

Hi Jonathan. Much thanks for your interest in Webina. Would you mind sending me a copy of the ligand and receptor? Also, what browser are you using? This certainly does sound like a bug, and it would be great to be able to correct it. Take care.

[Jacob Durrant]

Hi Nicolas. Much thanks for your interest in Gypsum-DL. Coincidentally, in the latest version (1.1.5) I changed the charge range to -4e/+4e (to accommodate ATP). So using the latest version, it should be possible to get the +4e form of your ligand.

But unless you use very permissive parameters, you’re unlikely to get the +4e form at physiological pH. To illustrate, let’s assume Gypsum-DL is only considering alternate protonation states and that there’s a 50/50 chance of protonating a given nitrogen. Since you have four such nitrogens, the chance of getting the +4e form would be 0.5 ^ 4, or one in sixteen. If you’re --max_variants_per_compound parameter is set to the default (5), you might not see the +4e form unless you run Gypsum-DL multiple times.

If you lower the pH, as you suggested, the chance of protonating increases, so you’re more likely to see +4e. (At low enough values, that’s the only form you’ll see.) Another option would be to ask Gypsum-DL top output more molecules. For examples, when I ran your molecule through the latest version using this command line (which is probably excessive):

python run_gypsum_dl.py --source tmp.smi --max_variants_per_compound 40 --thoroughness 1

I did see the +4e form.

Hope this makes sense! Thanks again for your interest in the software. Take care.

~Jacob

[Jacob Durrant]

Hi Emma. Much thanks for your interest in AutoGrow4, and thanks for identifying this bug. My student just updated the code. The fixed version can be found at https://git.durrantlab.pitt.edu/jdurrant/autogrow4/-/archive/master/autogrow4-master.zip

Would you mind letting me know if it works for you? If so, I’ll go ahead and push these changes to a new version.

After downloading the fixed version, you’ll need to clear the script’s cache. Here’s how:

python ../autogrow4/accessory_scripts/make_lineage_figures.py -o output/lineage1 -i output/Run_0/ \
--source_compound_file NCI_Top_300_Scores.smi --mol_name Gen_1_Cross_968450 \
--use_docked_source_compounds False --purge_previous_pickled_files True 

You should then be able to rerun the script without errors, like this:

python ../autogrow4/accessory_scripts/make_lineage_figures.py -o output/lineage1 -i output/Run_0/ \
--source_compound_file NCI_Top_300_Scores.smi --mol_name Gen_1_Cross_968450 \
--use_docked_source_compounds False --purge_previous_pickled_files False 

Take care.

[Jacob Durrant]

Hi Miro. Much thanks for your interest in Gypsum. This appears to be an error in the scipy or numpy libraries. Can you tell me which versions of those libraries you’re using? On my setup, I never see the error you mentioned:

Python 3.7.6 | packaged by conda-forge
numpy 1.18.5
scipy 1.4.1
rdkit 2020.03.1

[Jacob Durrant]

Hi Ricardo. Much thanks for your interest in BINANA, and please forgive my delay in responding. You can learn more about flexibility in the original BINANA paper: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3099006/#S6title

The same paper also describes the electrostatic interactions: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3099006/#S5title

Take care,

Jacob

[Jacob Durrant]

Hi Abylay. Much thanks for your interest in ProteinVR. I was able to reproduce the error on my computer. Unfortunately, the problem isn’t that ProteinVR can’t load the remote file. It’s that the server where the remote file is hosted won’t allow ProteinVR to access it. To fix the problem would require changes on the remote server itself. You may wish to contact the maintainer of molinstincts.com to see if they would be willing to change their server settings.

For what it’s worth, I’ve found that uploading SDF files to https://gist.github.com/ is a good way to make them publicly available. Here’s an example of loading a model from gist, in case it’s helpful: https://durrantlab.pitt.edu/pvr/?s=https://gist.githubusercontent.com/durrantlab/55ff21a12a851d3602efcddd7ad4f699/raw/baa70e29c7377fb07ba3e37e2783daffaa01eae3/1xdn.pdb&st0=All–Ligand–Stick–Element&st1=All–Protein–Cartoon–Spectrum&cx=0&cy=2.6281&cz=-8.0649&crx=0&cry=0.00001&crz=0&crw=-1&e=environs/blood/&sh=false&hs=true

I’m currently working on an update to ProteinVR that will allow users to upload files from their local computers too, eliminating the need for remote hosting all together.

Take care.

[Author]

Posts