Re: [OpenGrowth] OpenGrowth issues (?)

[Nicolas C. <nic...@gm...>]

 Hi,

* The number of grown ligands is set by NUMBER_OUTPUT. Usually I was
setting this parameter to a very high value (1000000 for example), and I
was stopping the program after a given amount of time (let's say a week) if
I had grown enough ligands.

* You said that some ligands were not built : in the input file you send
me, you set MIN_ATOMS to 10. As explained in user manual: "If the final
ligand has fewer heavy atoms than this number, it will not be saved. This
avoids molecules such as CH3-I to be saved for example". The unbuild
ligands had probably less than 10 atoms.

* If you still have clash, you need to change the VDW_SCALE_INTER
parameter. "The scale factor for intermolecular steric clashes. If the
distance between a ligand atom and a protein atom is less than this value
times the sum of their vdW radii, there is a steric clash and the ligand is
discarded". It is also used for choosing fragments. So fragments with
clashes should not be accepted.

* You described very branched ligands: did you play with BRANCHING_PROBA?

* If you pocket is small and buried, it is more likely that a clash will
appear and the new fragment will be rejected, which results in a growth
that is slower because it takes more iteration to find a good fragment.

Nicolas


Le jeu. 19 juil. 2018 à 17:05, ABRUSAN Gyorgy <Gyo...@ig...>
a écrit :

> Hi Nicolas,
>
>
> I did check the modified tool (compiles without issues), and there to be
> an improvement, but not really dramatic. (I used the same 5t8g structure
> for testing, and did not modify anything in OG, except compiling it with
> the new Parse.cpp file you have sent).
>
>
> The problems:
>
> 1. About 35% (7/20) of the structures are not built (no xyz file), but
> there is no error message why. There is a single error message about not
> being able to set up the force field. I ran OG in a verbose mode, and lots
> of fragments are rejected in these ligands, due to clashes, but the same is
> the case for ligands that are built succesfully, i.e. result in an .xyz
> file.
>
>
> 2. From the 14 ligands it made, in 2 the xyz files clearly clash (visibly)
> with the structure. When I dock all the ligands back, 3 of them clash (have
> positive energies).
>
>
> 3. A significant fraction of the grown ligands seem to have a star-like,
> not very realistic structure (given the the binding site is buried and
> elongeated), they are just visibly not a good fit to the pocket. (It seems
> as if OG tried to grow them radially from a central scaffold, while the
> original ligand of the structure is elongeated, so if this is the case that
> should be somehow taken into account)
>
>
> 4. The running time is slower, on the 2aqu structure that distributed with
> OG it is about 2-3 times higher than previously.
>
>
> Best wishes,
>
> Gyorgy
>
>
>
>
>
> ------------------------------
> *From:* ABRUSAN Gyorgy <Gyo...@ig...>
> *Sent:* 18 July 2018 10:17:49
> *To:* ope...@li...; Nicolas Cheron
> *Subject:* Re: [OpenGrowth] OpenGrowth issues (?)
>
>
> Ok, thanks. Is there a way of fixing the number of actually grown ligands?
> (I assume that if a halide results in a problem in setting up the force
> field, than it may not be a good idea to change this?) Typically, about
> 10-20% of  the ligands is skipped due to a halide, so I end up with less
> ligands in every run than I planned (and set in the input). It is not a big
> deal, but if there is a simple way of fixing it that would be good.
>
>
> Best wishes,
>
> Gyorgy
> ------------------------------
> *From:* Nicolas Cheron <nic...@gm...>
> *Sent:* 18 July 2018 08:15:51
> *To:* ope...@li...
> *Subject:* Re: [OpenGrowth] OpenGrowth issues (?)
>
> Hi,
>
> The first fragment has no real influence on the properties of the new
> molecules. Thus, not allowing an halide as a first fragment doesn't change
> anything, and it only avoids any problem with the setup of the force field.
>
> Nicolas
>
> Le mar. 17 juil. 2018 à 18:05, ABRUSAN Gyorgy <
> Gyo...@ig...> a écrit :
>
> Hi Nicolas,
>
>
> Thank you, I will check how does it perform. By the way, what is the
> reason for terminating growth when a halide is the first fragment? Does it
> make sense to change this? I have no particular reasons to use them.
>
>
> Best wishes,
>
> Gyorgy
> ------------------------------
> *From:* Nicolas Cheron <nic...@gm...>
> *Sent:* 17 July 2018 15:21:08
> *To:* ope...@li...
> *Subject:* Re: [OpenGrowth] OpenGrowth issues (?)
>
> 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.
>
> 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.
>
> ------------------------------------------------------------------------------
> 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
>