opengrowth-discuss — General discussion on OpenGrowth

Re: [OpenGrowth] Qusetions of opengrowth about SEED and REGROW

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

Hi,

Thank you for your interest in OpenGrowth. This error is coming from
OpenBabel. Are you sure it has been properly installed? Did you compile
yourself OpenBabel and OpenGrowth? Did you run the example files and are
they working?

Nicolas

Le ven. 29 janv. 2021 à 16:05, 程宇杰 <che...@ni...> a écrit :

> Hi!
>
> I am a PhD. Student from nibs. I am learning using your OpenGrowth, which
> seems really powerful for drug design.
>
> However, I have met some problems. They maybe seems silly but make me
> confused.
>
> Here are my questions:
>
> 1, when I use a given ligand as a seed, I meet "ERROR: Could not setup
> force field.", so how can i setup the ligand's force field?
>
> 2, when I use REGROW, the the same error will arise again. the first
> fragment i use is Aldehyde, which doesn't look like the error mentioned in
> manual.
>
> 3, are there any test files of SEED model and REGROW.
>
>
> ​Thank you very much; your support is greatly appreciated.
>
>
>
>
>
>
> _______________________________________________
> OpenGrowth-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrowth-discuss
>

[OpenGrowth] Qusetions of opengrowth about SEED and REGROW

[程宇杰 <che...@ni...>]

Hi!

I am a PhD. Student from nibs. I am learning using your OpenGrowth, which seems really powerful for drug design.

However, I have met some problems. They maybe seems silly but make me confused.

Here are my questions:

1, when I use a given ligand as a seed, I meet "ERROR: Could not setup force field.", so how can i setup the ligand's force field?

2, when I use REGROW, the the same error will arise again. the first fragment i use is Aldehyde, which doesn't look like the error mentioned in manual.

3, are there any test files of SEED model and REGROW. 




​Thank you very much; your support is greatly appreciated.

 

Re: [OpenGrowth] Linux Platform

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

Hello,

Thank you for your interests in the program. What are the names of the
files you are referring to ? How are you sure that these files are for
Windows ?

Best regards,

Nicolas

Le ven. 4 sept. 2020 à 14:54, brilliant nyathi <bn...@cu...> a écrit :

> Hello, I downloaded the opengrowth files however I am not seeing Linux
> executables but windows executables only.
>
> --
> Kind Regards
> Brilliant Nyathi
> Bsc Chemistry.Medicinal Chemistry(CUT)
> MPhil Medicinal Chemistry
> Drug Discovery and Informatics Research (DDIR) Group
> Chinhoyi University of Technology
> P. Bag 7724
> Chinhoyi
> Zimbabwe
> +263 78 320 6314
> Email: bn...@cu...
> skype: Brillie94
> _______________________________________________
> OpenGrowth-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrowth-discuss
>

[OpenGrowth] Linux Platform

[brilliant n. <bn...@cu...>]

Hello, I downloaded the opengrowth files however I am not seeing Linux
executables but windows executables only.

-- 
Kind Regards
Brilliant Nyathi
Bsc Chemistry.Medicinal Chemistry(CUT)
MPhil Medicinal Chemistry
Drug Discovery and Informatics Research (DDIR) Group
Chinhoyi University of Technology
P. Bag 7724
Chinhoyi
Zimbabwe
+263 78 320 6314
Email: bn...@cu...
skype: Brillie94

Re: [OpenGrowth] Any publications or feedback on OpenGrowth?

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

Dear Pil,

Sorry for the late reply, and thank you for your interests in OpenGrowth.

Regarding publications, I am not aware of any (yet).

Regarding feedback, we have some. The program has been used in the
Shakhnovich lab for several years. Some interesting molecules were
obtained, however we have always faced a quite high molecular complexity.
In other words, our best hits were complicated to synthesize. If you plan
to use OpenGrowth, my advice is thus either to design relatively small
molecules (MW at most 400 g/mol or so), or use the seed approach (for
example to fill a pocket).

Please let us know if you have other questions.

Best,

Nicolas

Le mar. 14 juil. 2020 à 19:08, Lee, Pil <pi...@me...> a écrit :

> Hi,
>
>
> I ran into the original paper in JMchem and the software recently and am
> very interested in trying this.
>
> I could not find any publications on OpenGrowth since the original
> publication.
>
>
> Does anyone know any publications on the results from using the software
> or any feedback on the program?
>
> Thanks.
>
>
>
>
> Pil H Lee, PhD
>
> Associate Research Scientist
> College of Pharmacy
> University of Michigan
> 428 Church St.
> Ann Arbor, MI 48109-1065
>
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should not
> be used for urgent or sensitive issues
> _______________________________________________
> OpenGrowth-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrowth-discuss
>

[OpenGrowth] Any publications or feedback on OpenGrowth?

[Lee, P. <pi...@me...>]

Hi,


I ran into the original paper in JMchem and the software recently and am very interested in trying this.

I could not find any publications on OpenGrowth since the original publication.


Does anyone know any publications on the results from using the software or any feedback on the program?

Thanks.




Pil H Lee, PhD

Associate Research Scientist
College of Pharmacy
University of Michigan
428 Church St.
Ann Arbor, MI 48109-1065

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues 

Re: [OpenGrowth] version 1.01

[Paulette G. <Pau...@sp...>]

Hi Nicolas,
Thanks for your response and explanations!

I did not attempt to compile the code myself.
However, now given your feedback I will re-visit the code since I have had positive experiences with de novo design packages in the past.

Best regards,

Paulette



From: Nicolas Cheron <nic...@gm...>
Sent: Thursday, August 8, 2019 12:04 PM
To: ope...@li...; Paulette Greenidge <Pau...@sp...>
Subject: Re: [OpenGrowth] version 1.01

Hi,

I am sorry for the late reply, this email get lost in all my emails. I didn't build the executables for v1.01 because it means for me preparing virtual machines and unfortunately I didn't have the time to do it ; moreover, the code seemed (to me) quite straightforward to compile. Did you have problems to compile the code by yourself? If yes, I can answer your questions.

The constraints in the output summary is "energy before optimization" - "energy after optimization". So yes, this value should be positive. Note however that these values should be used with great caution since they are computed at a crude level of energy.

Best,

Nicolas

Le jeu. 6 juin 2019 à 16:28, Paulette Greenidge <Pau...@sp...<mailto:Pau...@sp...>> a écrit :
Hi,

The advice is to use version 1.01 but unlike the 1.0.zip directory 1.01 does not contain
Linux executables. I have run the test example with version 1.0 and default settings (SMoG2016).
The constraint values of many of the generated ligands had very large values in this column.
If this corresponds to ligand strain energy shouldn’t the values be positive ?
Are the large values generated due to VDW scaling settings?
Is it possible to have the linux executables for version 1.01.

Thanks,

Paulette
_______________________________________________
OpenGrowth-discuss mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/opengrowth-discuss

Re: [OpenGrowth] version 1.01

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

Hi,

I am sorry for the late reply, this email get lost in all my emails. I
didn't build the executables for v1.01 because it means for me preparing
virtual machines and unfortunately I didn't have the time to do it ;
moreover, the code seemed (to me) quite straightforward to compile. Did you
have problems to compile the code by yourself? If yes, I can answer your
questions.

The constraints in the output summary is "energy before optimization" -
"energy after optimization". So yes, this value should be positive. Note
however that these values should be used with great caution since they are
computed at a crude level of energy.

Best,

Nicolas

Le jeu. 6 juin 2019 à 16:28, Paulette Greenidge <
Pau...@sp...> a écrit :

> Hi,
>
>
>
> The advice is to use version 1.01 but unlike the 1.0.zip directory 1.01
> does not contain
>
> Linux executables. I have run the test example with version 1.0 and
> default settings (SMoG2016).
>
> The constraint values of many of the generated ligands had very large
> values in this column.
>
> If this corresponds to ligand strain energy shouldn’t the values be
> positive ?
>
> Are the large values generated due to VDW scaling settings?
>
> Is it possible to have the linux executables for version 1.01.
>
>
>
> Thanks,
>
>
>
> Paulette
> _______________________________________________
> OpenGrowth-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrowth-discuss
>

[OpenGrowth] version 1.01

[Paulette G. <Pau...@sp...>]

Hi,

The advice is to use version 1.01 but unlike the 1.0.zip directory 1.01 does not contain
Linux executables. I have run the test example with version 1.0 and default settings (SMoG2016).
The constraint values of many of the generated ligands had very large values in this column.
If this corresponds to ligand strain energy shouldn't the values be positive ?
Are the large values generated due to VDW scaling settings?
Is it possible to have the linux executables for version 1.01.

Thanks,

Paulette

[OpenGrowth] Release of version 1.0.1

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

Dear OpenGrowth users,

I have just uploaded a new release of OpenGrowth. Eventhough the version
number seems only minor, it is an important update that corrects a bug that
was introduced when SMoG2016 was added to OpenGrowth instead of SMoG2015. I
recommended to every user to use this version.

Change log:
* reintroduction of the hardwall potential for SMoG2016 (VDW_SCALE_INTER
and VDW_SCALE_INTRA keywords).

You can get it from here: https://sourceforge.net/projects/opengrowth/files/

Happy growing,

Nicolas

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
>

[OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

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

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.
>

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

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

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.
>

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [OpenGrowth] OpenGrowth issues (?)

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

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
>

Re: [OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[OpenGrowth] OpenGrowth issues (?)

[ABRUSAN G. <Gyo...@ig...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.