Forum Replies Created
- Posts
Hi Maria. Much thanks for your interest in AutoGrow. You will need seed molecules to start AutoGrow, but you could use a seed library of small-molecule fragments that aren’t necessarily known to bind your target of interest. AutoGrow should (hopefully) be able to evolve those initial fragments into compounds with better predicted binding affinities. Hope this helps.
Re. the second error, can you confirm that your ""*_ranked.smi" files exist, and that they are not empty? It may be that rerunning AutoGrow with the corrected JSON file with correct this second issue as well.
Hi all. I noticed in your JSON file that "filename_of_receptor" is set to "./home/witte.t/autogrow4/tutorial/PARP/4r6eA_PARP1_prepared.pdb". Did you mean to include the initial "."? I suspect that’s the problem. Take care.
Hi Bryan. Much thanks for your interest in AutoGrow4. I wanted to let you know that we tested AutoGrow4 on macOS Mojave, not Catalina. If you happen to figure out your problem, please do let me know. But otherwise I’d recommend using the docker container if you want to run AutoGrow4 on Catalina. Take care.
Hi Christian. Re. the memory issue, you might want to try the latest version of Gypsum. I made some updates in version 1.1.7 that should reduce the amount of memory required. Take care.
Hi Marcos.You could try parameters like these:
--min_ph 7.0
--max_ph 7.0
--pka_precision 0.0
For what it’s worth, it looks like the pKa values of phenols vary quite a bit depending on other moieties: https://www.chem.ucla.edu/~cantrill/30A_S05/Acids_Bases_2.pdf
The average pKa value of the phenols used to parameterize Dimorphite-DL was particularly low: https://git.durrantlab.pitt.edu/jdurrant/dimorphite_dl/-/blob/1.2.4/site_substructures.smarts#L37
But I believe using the parameters above should always protonate your phenol molecules.
Take care,
Jacob
Hi Christian. Much thanks for this careful reading of the README.md file. It’s interesting that Open Babel calculates partial charges for MOL2 files but not PDBQT files. In this case, though, I don’t think it much matters, because I believe AutoDock Vina (surprisingly) doesn’t care about the partial charges listed in the PDBQT file: http://vina.scripps.edu/manual.html#:~:text=assigning%20atom,needed
Since Webina is based on the Vina codebase, I don’t think it cares about the partial charges either.
Take care,
JacobHi Rocío. Very exciting that you’re thinking about applying Autogrow in this way! The Autogrow 4 reaction set is much expanded, so there’s a chance it will be able to grow more of your fragments. It’s definitely worth a try. Autogrow 4 shouldn’t have any problem processing fewer compounds than the number described in the examples. Best of luck!
Hi Marcos. Much thanks for your interest in Gypsum. The algorithm isn’t actually deterministic, so it makes sense that you could get different outputs. Given your choice of min_ph, max_ph, and pka_precision, Gypsum is likely producing both the protonated and deprotonated form internally. But because max_variants_per_compound is 1, Gypsum must pick between the two. A certain percentage of the time it picks one, and at other times it picks the other. Hope this answer helps.
More details here: https://durrantlab.pitt.edu/forums/topic/a-few-problems/
Hi Christian. Sorry for my delay in getting back to you, and much thanks for bringing these issues to my attention. Excellent that you were able to debug the memory issue. Seems likely that others will run into this problem too, so I added a line to the
README.mdfile (to be included in future versions): https://git.durrantlab.pitt.edu/jdurrant/gypsum_dl/-/blob/master/README.md#memory-considerationsRegarding the four Chembridge compounds, I’m not surprised that Gypsum struggled to process them. They all contain adamantane substructures. I think what’s happening is that RDKit often fails to generate acceptable 3D coordinates for these constrained-ring structures, so Gypsum ends up throwing them out. In some cases, none of the generated structures are acceptable. To test this theory, I processed the following SMILES strings:
CC1=CC=CN2N=CC(C(=O)NC34CC5CC(C3)CC(C5)(C4)N3C=NC=N3)=C12 CCC12CC3CC(O)(C1)CC(C3)(C2)C(=O)N1CCN(CC1)C1CCOCC1 CCC12CC3CC(O)(C1)CC(C3)(C2)C(=O)N1CCN(CC1)C1=NC=CN=C1 CCC12CC3CC(O)(C1)CC(C3)(C2)C(=O)N1CCC(CC1)NS(C)(=O)=OWith these parameters:
{ "source": "t2.smi", "separate_output_files": true, "job_manager": "multiprocessing", "output_folder": "gypsum_dl_test_output_test2_mult/", "add_pdb_output": true, "num_processors": -1, "min_ph": 7.4, "max_ph": 7.4, "pka_precision": 1, "use_durrant_lab_filters": true, "thoroughness": 3, "max_variants_per_compound": 5 }Three of the four compounds failed.
But when I increased the
thoroughnessto 6, even whenmax_variants_per_compoundwas 1 to speed things up, only one compound failed, presumably because with these settings gypsum had more tries to get it right. I added some notes here: https://git.durrantlab.pitt.edu/jdurrant/gypsum_dl/-/blob/master/README.md#highly-constrained-ring-systemsRegarding the unusual substructures, these refer to MolVS-generated tautomers that Gypsum will discard. MolVS sometimes generates implausible tautomers, and throwing out inappropriate ones after-the-fact seemed like the best approach. Other, better-behaved tautomers generated from the parent compound could well be retained, though.
Thanks for all your help with this. It’s very helpful to have user feedback to improve the program.
Take care,
Jacob
Hi Sam. Much thanks for your interest in Pyrite. It does seem odd that it would take so long to load a five-frame trajectory. Have you removed the water molecules, I wonder? That could slow things down. If not, I’d be happy to test your trajectory on my setup to debug. I’ll send you a private message with my email address. Take care.
Hi Nicola. Much thanks for your interest in AutoGrow4. This is definitely a python problem, not an autogrow-specific problem. Somehow the version of python you’re using can’t find the rdkit module. It could have something to do with your alias setup, but I’m not certain.
Try directly running the same python executable you use for autogrow, and type in "import rdkit". Does it give you the same error?
You might also try the autogrow4 docker container, which tries to automate the installation of dependencies like these.
Good luck!
Much thanks for posting your solution, Ashim. This substructure was added to AutoGrow4 about two months ago, with the 4.0.2 update. So if your copy was older than that, it wouldn’t have had this feature yet. Take care.
Hi Ashim. Much thanks for your post. I did some investigating and found the source of the problem. AutoGrow4 uses Gypsum-DL to generate 3D molecules from SMILES strings, and Gypsum-DL in turn uses MolVS to identify alternate tautomeric forms. MolVS generally does a good job, but it occasionally creates inappropriate tautomers. That’s exactly what happened in this case.
Gypsum-DL includes a parameter,
--use_durrant_lab_filters, that allows users to discard SMILES with bad tautomers from a pre-defined list. I apparently ran into your same problem myself back in the day, because I found this line in the Gypsum-DL code:"O=[PH](=O)([#8])([#8])", # molvs does odd tautomer: OP(O)(O)=O => O=[PH](=O)(O)OThat’s the exact substructure you’re seeing.
So I think if you add
"use_durrant_lab_filters": trueto your AutoGrow4 JSON file, that will eliminate these bad tautomers.In testing Gypsum-DL with your
"max_variants_per_compound": 2,, though, I realized you might run into a second problem. Often both of the variants will contain the bad substructure, souse_durrant_lab_filterswill eliminate both. To better your chances that the program will identify variants of Acyclovir that survive the durrant-lab filters, I recommend increasingmax_variants_per_compound. When I used a value of5, I got several good SMILES strings.We’ve considered turning durrant-lab filters on by default, but decided not to to maintain backwards compatibility. It might be time for us to reconsider that decision, though, to avoid problems like these!
Hope this helps. Take care.
~Jacob
