Re: [OpenGrowth] OpenGrowth issues (?)
OpenGrowth is a program which constructs de novo ligands for proteins.
Brought to you by:
ncheron
From: Nicolas C. <nic...@gm...> - 2018-07-17 14:21:54
|
Hi, Sorry for the delay of answer, I had to dig a little bit in the program and re-run it to find the source of the problems. * Proba_FirstFrag.dat: here is an extract of the beginning of the file with the name of the fragment files and their chemical names that I have added: 0.11497049 Ring0_1 Hydroxyl 0.02205220 Ring0_2 Fluorine 0.00230765 Ring0_3 Cyano 0.00819452 Ring0_4 Aldehyde 0.00021193 Ring0_5 Nitroso 0.00580445 Ring0_6 Thiol 0.02081596 Ring0_7 Chlorine 0.00288456 Ring0_8 Nitro 0.00240184 Ring0_10 Bromine 0.00481546 Ring0_11 Iodine 0.51016760 Ring0_12 Methyl 0.04610594 Ring0_13 Amine 0.00128334 Ring0_15 Alkyne If you want to find this kind of information, it is quite straightforward: each line in Fragments.dat (with the name of a file) correspond to a line with a probability in Proba_FirstFrag.dat. Then, on each file (Ring0_2_1.xyz for example), you will find the chemical names at the beginning. To avoid the problem "ERROR: Could not set up force field", put 0.000 for Fluorine, Chlorine, Bromine, Iodine. To avoid " WARNING: damped steplength", put 0.000 for Hydroxyl. * Visualization problem: I agree that is is quite strange that PyMol draws molecules connected and not Chimera. The underlying problem is coming from the molecules, and hopefully with the fix below I hope it won't happen again. * I ran the program and also observed unconnected fragments, as well as other strange geometries (tilted phenyl groups or strange CH3). I had never seen this before and have found the source of the problem. Previously (when I was using SMOG2015 which was the beta version of SMOG2016) the VDW_SCALE_XXX parameters were used. When SMOG2016 was finished and incorporated in the program, these 2 parameters were turned off for this scoring function, and we didn't perform extensive tests. This causes the program to accept fragment which produces inter or intra molecular clashes. * To fix this, you need to change the Parse.cpp file: _ comment or remove lines 346 and 347 (with parameters.vdWScaleInter=0.01 and parameters.vdWScaleIntra=0.01) _ comment or remove lines 410 to 429 (the two conditions with "if (!parameters.vdWScaleInter) { ... }" and "if (!parameters.vdWScaleIntra) { ... }". _ I am joining a already modified file. _ then, recompile. The parameters VDW_SCALE_INTER and VDW_SCALE_INTRA in the input file will then be used. If you still have too many clashes with a value of 0.70, you can increase it. * For your test protein, some comments : _ you set OPTIMIZATION_STEEPDESC to 100, which is probably too high : this part is the most time-consuming part of the program. Check if with a lower value (20, e.g.) you still have too many clashes or a strange geometry _ you had a non integer value for MAX_ATOMS, which is strange (but not important) _ I don't know how OpenBabel handles proteins with gaps in details, but to avoid any problems I would avoid them. Chimera can model missing residues: (1) if the gaps are close from the binding site, you want to fill them; (2) if they are far from the binding site, how they are modelled is not really important so you can use the first model that Chimera proposes (or whatever software you prefer). It is likely the reason of why the program is slow with this protein. _ there is a branching_proba option if you want to have ligands that are less branched Please keep me posted if it solved your problems and if you still face other problems. Nicolas PS : and thank you for finding a bug in the program. I will release a 1.0.1 version that corrects this. Le lun. 16 juil. 2018 à 15:17, ABRUSAN Gyorgy <Gyo...@ig...> a écrit : > Hi Nicolas, > > > I wonder whether you have found the causes of the OpenGrowth errors I have > sent to you. > > > Best wishes, > > Gyorgy > ------------------------------ > *From:* Nicolas Cheron <nic...@gm...> > *Sent:* 10 July 2018 08:04:05 > *To:* ABRUSAN Gyorgy > *Subject:* Re: [OpenGrowth] OpenGrowth issues (?) > > Hi, > > I have seen your emails. I am out of town for a few days with difficult > access to internet. I will answer you before this Friday. > > Best, > > Nicolas > > Le lun. 9 juil. 2018 à 11:27, ABRUSAN Gyorgy <Gyo...@ig...> > a écrit : > > Hi Nicolas, > > > I have sent you an archive file with the problems, but it was returned > from the mailing list that it cannot be delivered due to its size (although > it is not particularly large). I wonder whether you have received it to > your other address, if not, I can send it again. > > > Best wishes, > > Gyorgy > > > ------------------------------ > *From:* ABRUSAN Gyorgy > *Sent:* 05 July 2018 13:27 > *To:* ope...@li...; Nicolas Cheron > *Subject:* Re: [OpenGrowth] OpenGrowth issues (?) > > > Hi Nicolas, > > > I re-run OG, compiled with OB2.4.1, using SMoG2016, and it still grows > ligands that clash with the binding site. (So far I did not re-dock them, > so some of them might be actually valid ligands). I attached a directory > with the protein I used, a molecular surface file (*.ms), two ligands that > clash, the OG input file, and the original ligand. > > > The protein chain does have gaps, that may contribute to the problem, > however the gaps are not close to the binding site. Also, the ligands do > not have the "right" look and feel, they are typically much more branched > and somehow twisted than real ligands in the pdb. It seems that OG somehow > struggles with this binding site. I wonder there is a simple solution (like > different parameters) for this. > > > Best wishes, > > Gyorgy > ------------------------------ > *From:* ABRUSAN Gyorgy <Gyo...@ig...> > *Sent:* 04 July 2018 16:25:50 > *To:* ope...@li... > *Subject:* Re: [OpenGrowth] OpenGrowth issues (?) > > > Hi Nicolas, > > > One more question - on my test protein (5t8g) growing ligands is > considerably slower than on the one included with OG (2aqu), 25min vs 4min. > Is there some way of speeding this up? The protein is a monomer, the > binding site is relatively small, but the ligand is almost completely > buried, that may make it more difficult to find fragments that do not clash > with the protein. > > > Gyorgy > ------------------------------ > *From:* ABRUSAN Gyorgy <Gyo...@ig...> > *Sent:* 04 July 2018 14:49:22 > *To:* ope...@li... > *Subject:* Re: [OpenGrowth] OpenGrowth issues (?) > > > Hi Nicolas, > > > 1.The unconnected fragments seem to be a visualization issue, they are > "unconnected" with Chimera, and connected with PyMol. I have to admit I am > bit surprised by this, my experience is that Chimera is a fairly well > established tool both for visualization and processing of ligands/receptors. > > > 2. Can you send a modified Proba_FirstFrag.dat file? I guess you have it > already. > > > 3. The structure which produces the clashes was processed with OG compiled > with OB 2.3.2, using SMOG2016. That could explain the problem. About 50% of > the 20 grown ligands could not be re-docked with Dock, and at least two of > them had extreme clashes. I will find out how the other OG version > performs. > > > Best wishes, > > Gyorgy > ------------------------------ > *From:* Nicolas Cheron <nic...@gm...> > *Sent:* 04 July 2018 12:30:38 > *To:* ope...@li... > *Subject:* Re: [OpenGrowth] OpenGrowth issues (?) > > Hi, > > 1. I recommend you to use OpenBabel 2.4.1 for several reasons: (1) > SMoG2016 was prepared with it (some atom types will be different with the > two versions of OpenBabel ; if someone wants to use OB 2.3.2, the > knowledge-based potential needs to be trained again), (2) it is faster in > some tasks, for example the 3mer screen. OpenGrowth does not use any of the > executables, it only needs the library. > > 2. The "ERROR: Could not set up force field" message is coming from > OpenBabel. It is discussed page 15 of the manual: " When the first chosen > fragment is a halide, you will very likely see “ERROR: Could not > setup force field”, the growth of this fragment will stop and a new growth > will start. This can be ignored. To avoid it, you can edit the file > Proba_FirstFrag.dat file and put 0.00000 at the lines defining halides. > This only impacts the choice of the first fragment, not the transition > probabilities so it won’t change anything to the molecules properties. This > disappears when halides are chosen later in the growth and not as the first > fragment. To know which fragments are what, you can look at the xyz files. > On the second line, you can find the name of the fragments, for example: > Ring0_2_1=fluorine, Ring0_7_1=chlorine, Ring0_10_1=bromine, > Ring0_11_1=iodine. When the first chosen fragment is hydroxyl, you may see > the following: “WARNING: damped steplength”. This can be safely ignored > since it is only a warning from OpenBabel." Did you change the halide lines > in Proba_FirstFrag.dat? If Yes and you still have that message, can you > please check if the first fragment is always the same in the grown > molecules? > > 3. I have never seen something like that (unconnected fragments). Are they > far from each other? Did you visually check them with different softwares > (could it be due to the criteria to draw a bond with your visualization > software)? If the problem is not coming from the visualization software, > can you please send me all your input files so I can try to reproduce the > problem? > > 4. Clashes should not happen. Something is going wrong. Which scoring > function are you using? In SMoG2016, there is a 1/r^12 term that prevents > this. In SMoG2001 there is a hard-wall potential that can be tuned in the > parameters (VDW_SCALE_INTER and VDW_SCAME_INTRA). If there was no problem > during the compilation of OpenBabel and OpenGrowth, you can send me your > input files so I can try here. > > Nicolas > > > > > Le lun. 2 juil. 2018 à 14:08, ABRUSAN Gyorgy <Gyo...@ig...> > a écrit : > > Hi Nicolas, > > > Just one correction, apparently my 2.4.1 OpenBabel wasn't installed (just > compiled locally and tested), thats one of the causes of the different file > structure, after recompiling and reinstalling it, and recompiling > opengrowth with it nothing changes, I still get the fragmented de novo > ligands. > > > Gyorgy > ------------------------------ > *From:* ABRUSAN Gyorgy <Gyo...@ig...> > *Sent:* 02 July 2018 10:40:40 > *To:* ope...@li... > *Subject:* [OpenGrowth] OpenGrowth issues (?) > > > Hi Nicolas, > > I ran a few tests with OG, and I have a few questions, also I think I > found a few issues, that might be bugs. I describe them below. > > > 1.Iinstallation of OpenBabel. I have both 2.3.2 and 2.4.1 installed > (locally), and complied OG with both versions, but right now I symlink only > the 2.3.2 executables in my home dir. Does OG use any of the OB > executables, or just the headers and shared objects? (Also, my 2.4.1 > installation has a different file structure than 2.3.2, there is no > openbabel-2.0 directory, the babelconfig.h header is located elsewhere than > the other headers, etc.; but once the correct paths are provided OG > compiles without issues.) > > > 2.I frequently get the "ERROR: Could not set up force field" error > message. Is it possible to fix this somehow? (their frequency varies, about > 10% of the ligands seem to produce this). > > > 3. Some of the ligands (*.xyz files) of OG (10-20%) contain unconnected > fragments (Even when I use your test protein, 2aqu). The OG compiled with > the OB 2.4.1. libraries appear to perform considerably worse in this > respect, but it happens also with the version complied with OB 2.3.2. Their > smiles seem to be okay though. > > > 4.When I use a different test protein (5t8g), with a relatively small and > deeply buried binding pocket, some of the grown ligands clash with the > protein, sometimes (although rarely) entire sidechains are grown "into" the > protein. Are there parameter combinations that may prevent this? > > > Best wishes, > > Gyorgy > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > OpenGrowth-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrowth-discuss > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > |