Re: [OpenBabel-Devel] Non-integer bond orders for resonant groups

[Noel O'Boyle]

OBBond.IsAromatic(). See the docs.

I would not use Smarts patterns to type atoms or bonds, but rather do it in
code. The former is just too error prone, slow and less readable.

On Tue, 27 Jul 2021, 07:18 David van der Spoel, 
wrote:

> On 2021-07-27 07:51, Noel O'Boyle wrote:
> > Is there a particular problem you are trying to solve where underlying
> > kekule representation is causing a problem?
> >
>
> Yes, I am extracting bond orders from OB and they go into my force field
> code. Different bond orders means different bond properties which in
> addition yield different charges in my force field code.
>
> If I understand it correctly the kekulization code checks for resonance
> but in order to get the chemistry of single and double bonds right we
> had to add over 100 lines to bondtyp.txt, so I am not sure that the code
> alone is enough.
>
> If it would be easy to extract the aromaticity of a bond that would be
> sufficient for my purpose indeed.
>
> >
> > On Mon, 26 Jul 2021, 21:28 David Koes,  > <mailto:dk...@pitt.edu>> wrote:
> >
> > In my opinion, if the only fractional value will be 1.5 then
> > non-integer
> > bond orders aren't worth the pain of breaking compatibility since
> > this
> > state can be (and is, for rings) represented by setting the aromatic
> > property of the bond.  Perhaps we should provide additional, more
> > nuanced properties to indicate resonance vs aromaticity?
> >
> > If there is a reason for fractions other than 1.5, then I think this
> > should be a separate property entirely (e.g., like formal charges vs
> > partial charges).
> >
> > I would point out that although O=CO is represented with a double and
> > single bond, the oxygens still get an identical partial charge as the
> > carboxylic acid group is recognized as such:
> > print(pybel.readstring('smi','O=CO').write('mol2'))
> >
> > David Koes
> >
> > Associate Professor
> > Computational & Systems Biology
> > University of Pittsburgh
> >
> > On 7/26/21 5:36 AM, David van der Spoel wrote:
> > > Hi,
> > >
> > > maybe this has been discussed earlier, but I would like to hear
> your
> > > opinion on implementing non-integer bond orders. For e.g.
> > benzene the
> > > average CC bond order would be 1.5, and likewise for COO- groups
> > or NOO
> > > groups. Quantum-chemically such resonant groups turn out to be
> > > symmetrical and e.g. with identical charges on the O in those
> cases.
> > >
> > > When using integer bond orders we are enforcing an asymmetry
> > that is not
> > > there. So would it be worthwhile implementing non-integer bond
> > orders or
> > > is there a workaround that I am overlooking?
> > >
> > > Cheers,
> > >
> > > --
> > > David van der Spoel, Ph.D.,
> > > Professor of Computational Molecular Biophysics
> > > Uppsala University.
> >
> >
> > ___
> > OpenBabel-Devel mailing list
> > OpenBabel-Devel@lists.sourceforge.net
> > <mailto:OpenBabel-Devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> > <https://lists.sourceforge.net/lists/listinfo/openbabel-devel>
> >
>
>
> --
> David van der Spoel, Ph.D.,
> Professor of Computational Molecular Biophysics
> Uppsala University.
> http://virtualchemistry.org
>
>
>
>
>
>
>
>
>
> När du har kontakt med oss på Uppsala universitet med e-post så innebär
> det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör
> det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
>
> E-mailing Uppsala University means that we will process your personal
> data. For more information on how this is performed, please read here:
> http://www.uu.se/en/about-uu/data-protection-policy
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Python bindings for 3.1.1

[Noel O'Boyle]

Hi all,

I've just uploaded Windows binaries for the Python bindings to PyPI. This
took quite a while due to some issues with Swig.

Swig 4.0.1 is out, and looks pretty interesting (e.g. Doxygen comments can
be included in the Python bindings), but...it doesn't work for us. They've
overhauled the Python support apparently, and now "import openbabel" just
fails, and not in an informative way.

So for now, I'm using Swig 3.0.12 - which is from 2017. As a result, we
don't support Python 3.8 at the moment.

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Last call for 3.0.1 release

[Noel O'Boyle]

Would you consider a beta release first? I won't be able to get things
together by Friday.

- Noel

On Mon, 27 Apr 2020, 16:06 Geoffrey Hutchison, 
wrote:

> I'd like to make a 3.0.1 release on Friday - it's sorely needed. Any last
> issues or patches to consider before the release?
>
> -Geoff
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Migrating to GitHub build actions

[Noel O'Boyle]

Looks great so far. EIGEN3 is in the msvc dependencies that you've
untarred. It should just be a matter of
-DEIGEN3_INCLUDE_DIR=MSVC_DEPS_DIR\include".

On Fri, 10 Apr 2020, 00:52 Geoffrey Hutchison, 
wrote:

> Hi Noel,
>
> I've been working bit-by-bit to migrate OB's test builds from Travis /
> Appveyor to the new GitHub action infrastructure. (Microsoft, which now
> owns GH is evidently providing tons of cloud resources.)
>
> Good news:
> - Linux (Ubuntu) builds for standard and SWIG builds
> - Mac build
>
> I have not yet figured out how to get all the MSVC dependencies installed.
> The big hangup seems to be Eigen3.
>
> If someone wants to set up some CMake magic to optionally download Eigen3
> along the lines of RapidJSON .. it would be greatly appreciated.
>
> -Geoff
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Travis CI no longer running on PRs

[Noel O'Boyle]

Looking at the link in that tweet you Liked, Geoff, it may be that we need
to transition to the Travis GitHub App, rather than whatever we were doing.
Or are we on that already?

- Noel

On Wed, 8 Apr 2020 at 09:45, Noel O'Boyle  wrote:

> I've just checked a few PRs and it seems that the Travis CI is not being
> run. The Appveyor build is running, but I don't think that runs the tests.
>
> Regards,
> - Noel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Travis CI no longer running on PRs

[Noel O'Boyle]

I've just checked a few PRs and it seems that the Travis CI is not being
run. The Appveyor build is running, but I don't think that runs the tests.

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Willing to contribute to Openbabel

[Noel O'Boyle]

A fairly easy first issue would be to fix the two warnings found when
compiling with a recent gcc. Note that a simple loop should be preferred
over expressions that involve recent C++ standards (due to portability).

Regards,
- Noel

On Thu, 13 Feb 2020 at 14:15, Naruki Yoshikawa 
wrote:

> Hello Hashim and other future GSoC candidates,
>
> I am a former GSoC student. I worked on the 3D structure generation of
> Open Babel in GSoC 2018 and 2019.
> https://summerofcode.withgoogle.com/archive/2018/projects/5957928301363200/
> https://summerofcode.withgoogle.com/archive/2019/projects/5300703310905344/
> Here is our paper based on the GSoC project:
> https://jcheminf.biomedcentral.com/articles/10.1186/s13321-019-0372-5
>
> I have some works left related to my project.
> As I cannot join GSoC anymore, I hope someone would solve the following
> problems.
>
> 1. Stereochemistry:
> I found out something is wrong
> with OBDistanceGeometry::CheckStereoConstraints(), but I still don't
> understand what is wrong.
> I posted some problematic cases before.
> https://sourceforge.net/p/openbabel/mailman/message/36699127/
> 
> The function is replaced now, but it is still problematic.
> It compares canonical SMILES of input and output, but when I generate
> canonical SMILES from generated 3D structures, SMILES sometimes don't
> match.
> We need to fix this problem.
>
> If you can list problematic test cases, it would help us to solve the
> issue.
> I think this is an easy task and a good starting point to start
> contribution. You can create an issue to report problematic cases.
>
> Here are related codes and discussions:
> https://github.com/openbabel/openbabel/pull/1875#issuecomment-547242242
>
> https://github.com/openbabel/openbabel/blob/6e80d6548e04af1dc13f9ff975f18714c7024617/src/distgeom.cpp#L912
>
> https://github.com/openbabel/openbabel/blob/6e80d6548e04af1dc13f9ff975f18714c7024617/test/testdistgeom.py#L24
>
> You can use our test dataset at
> https://github.com/n-yoshikawa/ob-fragment-generation/tree/master/data
>
> 2. Improve performance:
> I wrote distance geometry last year, but it was so slow compared to
> RDKit's.
> If you can improve the performance, it is great.
> The slowest part was error minimization in my evaluation.
>
> https://github.com/openbabel/openbabel/blob/6e80d6548e04af1dc13f9ff975f18714c7024617/src/distgeom.cpp#L1171
> I doubt initial geometry is strange due to loose distance constraints, but
> I am not so sure.
>
> 3. Large ring:
> The default fragment-based coordinate generation works poorly for unknown
> large ring fragments.
> Geoff attempted to solve this, but it is not complete yet.
> https://github.com/openbabel/openbabel/pull/2019
> Using distance geometry for unknown fragment is another possible solution,
> but the performance was poor in my implementation.
>
> I used a lot of technical terms here. Please let me know if you have any
> questions.
>
> Naruki
>
> 2020年2月13日(木) 3:17 Hashim Chaudhry :
>
>> Hello Devs,
>>
>> I'm really looking to contribute to Openbabel however, I'm having a hard
>> time figuring out where to start. I'd really appreciate if someone could
>> point me in the right direction.
>>
>> *Why I want to contribute?*
>> I came across an Openbabel GSOC project idea (Develop a validation and
>> standardization filter) at Openchemistry.org and it piqued my interest.
>> I'm well aware that the organizations haven't been announced yet,
>> nevertheless, I'm looking to contribute to Openbabel to get a start in
>> Open-Source work and get familiar with the code-base before GSOC.
>>
>> *About Me*
>> I'm a third-year Computer Science undergrad student. I have completed a
>> number of self learning courses for Programming, Data Structures,
>> Machine Learning and Data Science(with Python).
>> I believe these courses have laid a foundation that would really help me
>> to learn and contribute to Openbabel.
>>
>> Moreover, here's a link to my Kaggle profile
>> . I'm a beginner finding my way
>> into Data Science. It ain't much, but it's honest work.
>>
>> Regards,
>> Hashim
>> ReplyReply to allForward
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Docs on handling of stereo

[Noel O'Boyle]

I believe I've covered the issues you've raised, but let me know if not.
I'll also mention this on Twitter to see if anyone has anything to add.

https://github.com/openbabel/documentation/pull/15

On Tue, 11 Feb 2020 at 19:54, Noel O'Boyle  wrote:

> Hi Stefano,
>
> When you call GetConfig() you are setting the winding yourself. I see now
> that this wasn't clear. By default, you are saying "give me the atoms in
> clockwise order looking from atom x". In other words, you will never need
> to check the winding of a config - you will always know it - it'll be
> whatever you set when you called GetConfig().
>
> While you can use the first example on the page to iterate through
> OBStereoData and check for cases of ob.OBStereo.TrigonalBipyramidal if you
> want, there's no code in the library to perceive these from 3D structures,
> so they will never exist. The only thing we do have right now beyond tetra
> and cistrans is square planar from SMILES ("Cl[Pt@SP1](F)(I)Br"), and
> even that is not perceived.
>
> Regards,
> - Noel
>
> On Tue, 11 Feb 2020 at 16:20, Stefano Forli  wrote:
>
>> Hi Noel,
>> indeed, that was my initial attempt to figure out how to deal with
>> stereogenic centers,
>> and I still didn't have a decent understanding of Id vs Idx.
>> Incidentally, this is particularly clear in your documentation.
>>
>> I have one suggestion.
>> In the section about the inversion of stereochemistry, it would be
>> helpful if the example
>> would show how to read the current winding.
>> For example, would this work?
>>
>> --
>> if config.winding == ob.OBStereo.Clockwise:
>>  print("Clockwise winding")
>> elif config.winding==ob.OBStereo.AntiClockwise:
>>  print("Anti-clockwise winding")
>> else: # elif config.winding==ob.OBStereoUnknownWinding: ?
>>  print("Undefined winding winding")
>> --
>>
>> Also, I know the support for non-tetrahedral chirality is not complete,
>> but I'm wondering
>> if there a way to use the OBStereo.Type with the facade to infer if it is
>> recognized or not.
>>
>> Thanks!
>>
>> S
>>
>> On 2020-02-09 12:36, Noel O'Boyle wrote:
>> > Just a note on the code above. Many years ago Tim replaced the
>> stereochemistry handling,
>> > and I helped a bit. But vestiges of the original handling were left
>> lying around to avoid
>> > breaking the API. I guess we thought we'd remove them sooner than we
>> did, as looking back
>> > it makes no sense to have them lying around confusing everyone.
>> >
>> > Anyway, now with version 3.0, mol.FindChiralCenters() and
>> atom.HasChiralitySpecified()
>> > have both been removed. atom.IsChiral() I kept (though I thought about
>> removing it also)
>> > but changed the code so that it's now a convenience function that just
>> calls the functions
>> > in the modern API.
>> >
>> > And just to note that you should avoid subtracting 1 from the Idx to
>> get the Id. Right now
>> > it works, but we don't guarantee that relationship, and it certainly
>> won't be true if you
>> > delete atoms. Better to get the atom and then call GetId().
>> >
>> > - Noel
>> >
>> > On Thu, 6 Feb 2020 at 06:58, Stefano Forli > fo...@scripps.edu>>
>> > wrote:
>> >
>> > Noel,
>> > this is great! I've been following the stereochemistry issue for a
>> while in the mailing
>> > list and you addressed pretty much all the key aspects.
>> >
>> > One thing that seems to be missing is the discussion on how to
>> invert chirality. In the
>> > past I've tried writing code to enumerate all possible enantiomers
>> of molecules with
>> > unspecified chiral centers or to explicitly invert the defined ones.
>> >
>> > An issue found while digging into that was that
>> OBAtom.HasChiralitySpecified(), and
>> > facade.GetTetrahedralStereo(idx).IsSpecified() were giving
>> conflicting results.
>> >
>> > It's been a while since I tested it, but the code was this:
>> > 
>> > import pybel
>> > ob = pybel.ob
>> > mols = [ 'OCC1OC(O)C(O)C(O)C1O',
>> >  'OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O']
>> > for smi in mols:
>> > print "\nMOL->", smi
>> > m = pybel.readstring('smi', smi).OBMol
>> > m.FindChiralCenters()
>> >   

Re: [OpenBabel-Devel] Docs on handling of stereo

[Noel O'Boyle]

Hi Stefano,

When you call GetConfig() you are setting the winding yourself. I see now
that this wasn't clear. By default, you are saying "give me the atoms in
clockwise order looking from atom x". In other words, you will never need
to check the winding of a config - you will always know it - it'll be
whatever you set when you called GetConfig().

While you can use the first example on the page to iterate through
OBStereoData and check for cases of ob.OBStereo.TrigonalBipyramidal if you
want, there's no code in the library to perceive these from 3D structures,
so they will never exist. The only thing we do have right now beyond tetra
and cistrans is square planar from SMILES ("Cl[Pt@SP1](F)(I)Br"), and even
that is not perceived.

Regards,
- Noel

On Tue, 11 Feb 2020 at 16:20, Stefano Forli  wrote:

> Hi Noel,
> indeed, that was my initial attempt to figure out how to deal with
> stereogenic centers,
> and I still didn't have a decent understanding of Id vs Idx.
> Incidentally, this is particularly clear in your documentation.
>
> I have one suggestion.
> In the section about the inversion of stereochemistry, it would be helpful
> if the example
> would show how to read the current winding.
> For example, would this work?
>
> --
> if config.winding == ob.OBStereo.Clockwise:
>  print("Clockwise winding")
> elif config.winding==ob.OBStereo.AntiClockwise:
>  print("Anti-clockwise winding")
> else: # elif config.winding==ob.OBStereoUnknownWinding: ?
>  print("Undefined winding winding")
> --
>
> Also, I know the support for non-tetrahedral chirality is not complete,
> but I'm wondering
> if there a way to use the OBStereo.Type with the facade to infer if it is
> recognized or not.
>
> Thanks!
>
> S
>
> On 2020-02-09 12:36, Noel O'Boyle wrote:
> > Just a note on the code above. Many years ago Tim replaced the
> stereochemistry handling,
> > and I helped a bit. But vestiges of the original handling were left
> lying around to avoid
> > breaking the API. I guess we thought we'd remove them sooner than we
> did, as looking back
> > it makes no sense to have them lying around confusing everyone.
> >
> > Anyway, now with version 3.0, mol.FindChiralCenters() and
> atom.HasChiralitySpecified()
> > have both been removed. atom.IsChiral() I kept (though I thought about
> removing it also)
> > but changed the code so that it's now a convenience function that just
> calls the functions
> > in the modern API.
> >
> > And just to note that you should avoid subtracting 1 from the Idx to get
> the Id. Right now
> > it works, but we don't guarantee that relationship, and it certainly
> won't be true if you
> > delete atoms. Better to get the atom and then call GetId().
> >
> > - Noel
> >
> > On Thu, 6 Feb 2020 at 06:58, Stefano Forli  fo...@scripps.edu>>
> > wrote:
> >
> > Noel,
> > this is great! I've been following the stereochemistry issue for a
> while in the mailing
> > list and you addressed pretty much all the key aspects.
> >
> > One thing that seems to be missing is the discussion on how to
> invert chirality. In the
> > past I've tried writing code to enumerate all possible enantiomers
> of molecules with
> > unspecified chiral centers or to explicitly invert the defined ones.
> >
> > An issue found while digging into that was that
> OBAtom.HasChiralitySpecified(), and
> > facade.GetTetrahedralStereo(idx).IsSpecified() were giving
> conflicting results.
> >
> > It's been a while since I tested it, but the code was this:
> > 
> > import pybel
> > ob = pybel.ob
> > mols = [ 'OCC1OC(O)C(O)C(O)C1O',
> >  'OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O']
> > for smi in mols:
> > print "\nMOL->", smi
> > m = pybel.readstring('smi', smi).OBMol
> > m.FindChiralCenters()
> > facade = ob.OBStereoFacade(m)
> > for a in ob.OBMolAtomIter(m):
> > if a.IsChiral():
> > idx = a.GetIdx()
> > print "ATOM", a.GetIdx(), a.IsChiral(),
> >  a.HasChiralitySpecified(),
> > print
> facade.GetTetrahedralStereo(idx-1).IsSpecified()
> > ===
> >
> > It would be interesting to test it with the latest development code
> and see if there are
> > still issues.
> >
> > Thas
> >
> > On 2020-02-05 14:51, Geoffrey 

Re: [OpenBabel-Devel] Docs on handling of stereo

[Noel O'Boyle]

Just a note on the code above. Many years ago Tim replaced the
stereochemistry handling, and I helped a bit. But vestiges of the original
handling were left lying around to avoid breaking the API. I guess we
thought we'd remove them sooner than we did, as looking back it makes no
sense to have them lying around confusing everyone.

Anyway, now with version 3.0, mol.FindChiralCenters() and
atom.HasChiralitySpecified() have both been removed. atom.IsChiral() I kept
(though I thought about removing it also) but changed the code so that it's
now a convenience function that just calls the functions in the modern API.

And just to note that you should avoid subtracting 1 from the Idx to get
the Id. Right now it works, but we don't guarantee that relationship, and
it certainly won't be true if you delete atoms. Better to get the atom and
then call GetId().

- Noel

On Thu, 6 Feb 2020 at 06:58, Stefano Forli  wrote:

> Noel,
> this is great! I've been following the stereochemistry issue for a while
> in the mailing
> list and you addressed pretty much all the key aspects.
>
> One thing that seems to be missing is the discussion on how to invert
> chirality. In the
> past I've tried writing code to enumerate all possible enantiomers of
> molecules with
> unspecified chiral centers or to explicitly invert the defined ones.
>
> An issue found while digging into that was that
> OBAtom.HasChiralitySpecified(), and
> facade.GetTetrahedralStereo(idx).IsSpecified() were giving conflicting
> results.
>
> It's been a while since I tested it, but the code was this:
> 
> import pybel
> ob = pybel.ob
> mols = [ 'OCC1OC(O)C(O)C(O)C1O',
> 'OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O']
> for smi in mols:
>print "\nMOL->", smi
>m = pybel.readstring('smi', smi).OBMol
>m.FindChiralCenters()
>facade = ob.OBStereoFacade(m)
>for a in ob.OBMolAtomIter(m):
>if a.IsChiral():
>idx = a.GetIdx()
>print "ATOM", a.GetIdx(), a.IsChiral(),
> a.HasChiralitySpecified(),
>print facade.GetTetrahedralStereo(idx-1).IsSpecified()
> ===
>
> It would be interesting to test it with the latest development code and
> see if there are
> still issues.
>
> Thas
>
> On 2020-02-05 14:51, Geoffrey Hutchison wrote:
> > Yes, Naruki and I were running into confusion when using these classes
> for the distance
> > geometry implementation.
> >
> > The key challenge is that we'd want to save the expected stereo
> configuration around atoms
> > and bonds - and then when generating 3D coordinates, test to see if the
> generated
> > configurations match the expected ones.
> >
> > I think we can probably go through the code and examine, but if you have
> suggestions on
> > how to save the expected configs for future comparison, that would be
> great.
> >
> > -Geoff
> >
> >
> >> On Feb 5, 2020, at 4:30 PM, Noel O'Boyle  >> <mailto:baoille...@gmail.com>> wrote:
> >>
> >> Hi there,
> >>
> >> I've been very slowly pulling together some docs on using the API for
> stereo. I remember
> >> someone on the list a few months back discussing difficulties with this
> part of the
> >> library - if anyone has any particular examples they'd like me to
> discuss, this would be
> >> a good time to mention them.
> >>
> >> Progress so far:
> >>
> https://github.com/baoilleach/documentation/blob/stereo/Stereochemistry/stereo.rst
> >>
> >> Regards,
> >> - Noel
> >> ___
> >> OpenBabel-Devel mailing list
> >> OpenBabel-Devel@lists.sourceforge.net  OpenBabel-Devel@lists.sourceforge.net>
> >> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> >
> >
> >
> > ___
> > OpenBabel-Devel mailing list
> > OpenBabel-Devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> >
>
> --
>
>   Stefano Forli, PhD
>
>   Assistant Professor
>   Center for Computational Structural Biology
>
>   Dept. of Integrative Structural
>   and Computational Biology, MB-112A
>   The Scripps Research Institute
>   10550  North Torrey Pines Road
>   La Jolla,  CA 92037-1000,  USA.
>
>  tel: +1 (858)784-2055
>  fax: +1 (858)784-2860
>  email: fo...@scripps.edu
>  http://www.scripps.edu/~forli/
>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Docs on handling of stereo

[Noel O'Boyle]

Excellent suggestions for examples and/or areas of focus. I'll refer back
to these as I work through the docs.

Actually now I remember that it was your earlier email Stefano that
prompted me to write these docs. I started at the time, but lost the file,
and/or moved jobs, etc.

On Thu, 6 Feb 2020 at 06:58, Stefano Forli  wrote:

> Noel,
> this is great! I've been following the stereochemistry issue for a while
> in the mailing
> list and you addressed pretty much all the key aspects.
>
> One thing that seems to be missing is the discussion on how to invert
> chirality. In the
> past I've tried writing code to enumerate all possible enantiomers of
> molecules with
> unspecified chiral centers or to explicitly invert the defined ones.
>
> An issue found while digging into that was that
> OBAtom.HasChiralitySpecified(), and
> facade.GetTetrahedralStereo(idx).IsSpecified() were giving conflicting
> results.
>
> It's been a while since I tested it, but the code was this:
> 
> import pybel
> ob = pybel.ob
> mols = [ 'OCC1OC(O)C(O)C(O)C1O',
> 'OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O']
> for smi in mols:
>print "\nMOL->", smi
>m = pybel.readstring('smi', smi).OBMol
>m.FindChiralCenters()
>facade = ob.OBStereoFacade(m)
>for a in ob.OBMolAtomIter(m):
>if a.IsChiral():
>idx = a.GetIdx()
>print "ATOM", a.GetIdx(), a.IsChiral(),
> a.HasChiralitySpecified(),
>print facade.GetTetrahedralStereo(idx-1).IsSpecified()
> ===
>
> It would be interesting to test it with the latest development code and
> see if there are
> still issues.
>
> Thas
>
> On 2020-02-05 14:51, Geoffrey Hutchison wrote:
> > Yes, Naruki and I were running into confusion when using these classes
> for the distance
> > geometry implementation.
> >
> > The key challenge is that we'd want to save the expected stereo
> configuration around atoms
> > and bonds - and then when generating 3D coordinates, test to see if the
> generated
> > configurations match the expected ones.
> >
> > I think we can probably go through the code and examine, but if you have
> suggestions on
> > how to save the expected configs for future comparison, that would be
> great.
> >
> > -Geoff
> >
> >
> >> On Feb 5, 2020, at 4:30 PM, Noel O'Boyle  >> <mailto:baoille...@gmail.com>> wrote:
> >>
> >> Hi there,
> >>
> >> I've been very slowly pulling together some docs on using the API for
> stereo. I remember
> >> someone on the list a few months back discussing difficulties with this
> part of the
> >> library - if anyone has any particular examples they'd like me to
> discuss, this would be
> >> a good time to mention them.
> >>
> >> Progress so far:
> >>
> https://github.com/baoilleach/documentation/blob/stereo/Stereochemistry/stereo.rst
> >>
> >> Regards,
> >> - Noel
> >> ___
> >> OpenBabel-Devel mailing list
> >> OpenBabel-Devel@lists.sourceforge.net  OpenBabel-Devel@lists.sourceforge.net>
> >> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> >
> >
> >
> > ___
> > OpenBabel-Devel mailing list
> > OpenBabel-Devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> >
>
> --
>
>   Stefano Forli, PhD
>
>   Assistant Professor
>   Center for Computational Structural Biology
>
>   Dept. of Integrative Structural
>   and Computational Biology, MB-112A
>   The Scripps Research Institute
>   10550  North Torrey Pines Road
>   La Jolla,  CA 92037-1000,  USA.
>
>  tel: +1 (858)784-2055
>  fax: +1 (858)784-2860
>  email: fo...@scripps.edu
>  http://www.scripps.edu/~forli/
>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Docs on handling of stereo

[Noel O'Boyle]

Hi there,

I've been very slowly pulling together some docs on using the API for
stereo. I remember someone on the list a few months back discussing
difficulties with this part of the library - if anyone has any particular
examples they'd like me to discuss, this would be a good time to mention
them.

Progress so far:
https://github.com/baoilleach/documentation/blob/stereo/Stereochemistry/stereo.rst

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Why are there plugins?

[Noel O'Boyle]

Here are some timings for "obabel -:C -osmi" for the first run of the day
(note that OB here is on a network drive so I would guess this will be
slower than for most other people):

real 0m1.981s
user 0m0.029s
sys 0m0.086s

and the second:

real 0m0.032s
user 0m0.020s
sys 0m0.010s

Personally, I don't see this as a problem, and I have no interest in making
a complex system even more complex.

Regards,
- Noel


On Wed, 8 Jan 2020 at 18:53, Geoffrey Hutchison 
wrote:

> > In theory one could load only the plugins needed and in that way save
> startup time and memory. However in OB, once you load one plugin all
> plugins are loaded (one by one, making it slow).
>
> Sounds like a great project. If you or anyone else wants to improve the
> plugin loading code to load on demand, please let me know.
>
> Open Babel is a purely volunteer project, so features are added / coded
> when people have a need and write the code.
>
> It's been ages since I benchmarked the plugin loading code (i.e., well
> over 10 years) but my conclusion back then was that:
> - it's a meaningful time delay for short tasks, but those are fast anyway
> - when you're repeating short tasks (e.g., using the obabel binary
> repeatedly in a shell script) most of the plugins get cached by modern OS
> - for long tasks, it's not the time-limiting step
>
> There were two reasons for them:
> - they're much easier to write than adding to a monolithic library. (Does
> anyone want 100 API calls for different formats, etc.?)
> - they can be offloaded as needed by the OS
>
> I'm sure someone could code up an index/cache to improve plugin loading.
> Please do.
>
> In the meantime, as you note, it's possible to compile static and/or hack
> the build as you wish.
>
> -Geoff
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Why are there plugins?

[Noel O'Boyle]

If you delete all of the plugins you don't want, this will speed things up
for you.

Alternatively, if you make a static build (I forgot the precise
invocation), then the plugins are compiled in rather than loaded
dynamically.

I don't have time right now to go into why plugins are a great idea, but
hopefully the suggestions above will sort out your immediate problems.

Regards,
- Noel

On Wed, 8 Jan 2020 at 13:51, David van der Spoel 
wrote:

> Hi,
>
> I am trying to debug some code that links to OpenBabel and wonder why
> there are plugins for everything?
>
> In theory one could load only the plugins needed and in that way save
> startup time and memory. However in OB, once you load one plugin all
> plugins are loaded (one by one, making it slow).
>
> So is there any rationale for these or should we phase them out?
>
> Cheers,
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> http://www.icm.uu.se
>
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Hydrogen management bug

[Noel O'Boyle]

Should have used vim. :-)

On Tue, 26 Nov 2019 at 13:12, David van der Spoel 
wrote:

> Den 2019-11-26 kl. 13:58, skrev Noel O'Boyle:
> > The "M  CHG" line looks dubious. It states that there is a single
> > charge, a +5 charge on atom 1. What is the source of this SDF file?
>
> Emacs :(
>
> >
> > Regards,
> > - Noe
> >
> > On Tue, 26 Nov 2019 at 12:12, David van der Spoel  > <mailto:sp...@xray.bmc.uu.se>> wrote:
> >
> > Den 2019-11-26 kl. 13:06, skrev Noel O'Boyle:
> >  > Hi David,
> >  >
> >  > Can you provide the input file?
> > Attached, thanks for looking into this.
> >  >
> >  > Regards,
> >  > - Noel
> >  >
> >  > On Tue, 26 Nov 2019 at 09:50, David van der Spoel
> > mailto:sp...@xray.bmc.uu.se>
> >  > <mailto:sp...@xray.bmc.uu.se <mailto:sp...@xray.bmc.uu.se>>>
> wrote:
> >  >
> >  > Den 2019-11-26 kl. 10:12, skrev Noel O'Boyle:
> >  >  > An SDF file describes the number of hydrogens on each
> > atom. Open
> >  > Babel
> >  >  > is neither adding nor removing them. AddHydrogens() is just
> >  > making them
> >  >  > explicit.
> >  > Unfortunately, no. The structure below has 7 hydrogens and
> > one charge
> >  > but obprop adds one H and 4 (!) charges.
> >  >
> >  > % obprop 2-aminoguanidinium.sdf
> >  > name 2-aminoguanidinium.sdf 1
> >  > formula  CH8N4+
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >OpenBabel11261907103D
> >  >
> >  >12 11  0  0  0  0  0  0  0  0999 V2000
> >  >  -1.5988   -0.61390.0135 N   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >  -0.46551.3957   -0.0077 N   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >   0.7405   -0.61230.0118 N   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >   1.93920.11530.0724 N   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >  -0.44810.06070.0074 C   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >  -1.6144   -1.62500.0385 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >  -2.4894   -0.13450.0041 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >  -1.31861.9349   -0.0175 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >   0.41731.8753   -0.1389 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >   1.96960.65690.9451 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >   2.7365   -0.53220.1048 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  >   0.8109   -1.6139   -0.1611 H   0  0  0  0  0  0  0  0
> > 0  0  0  0
> >  > 1  6  1  0  0  0  0
> >  > 2  8  1  0  0  0  0
> >  > 4  3  1  0  0  0  0
> >  > 4 11  1  0  0  0  0
> >  > 4 10  1  0  0  0  0
> >  > 5  1  1  0  0  0  0
> >  > 5  2  1  0  0  0  0
> >  > 5  3  1  0  0  0  0
> >  > 7  1  1  0  0  0  0
> >  > 9  2  1  0  0  0  0
> >  >12  3  1  0  0  0  0
> >  > M  CHG  1   1   5
> >  > M  END
> >  >
> >  >  >
> >  >  > Regards,
> >  >  > - Noel
> >  >  >
> >  >  > On Tue, 26 Nov 2019 at 06:50, David van der Spoel
> >  > mailto:sp...@xray.bmc.uu.se>
> > <mailto:sp...@xray.bmc.uu.se <mailto:sp...@xray.bmc.uu.se>>
> >  >  > <mailto:sp...@xray.bmc.uu.se <mailto:sp...@xray.bmc.uu.se>
> > <mailto:sp...@xray.bmc.uu.se <mailto:sp...@xray.bmc.uu.se>>>> wrote:
> >  >  >
> >  >  > Hi,
> >  >  >
> >  >  > I was trying to use obprop on an SDF file, but found
> > out that
> >  > it adds
> >  >  > one hydrogen to my compound that should not be there.
> > I then
> >  > went to
> >  >  > look at the code and removed these two lines
> > 

Re: [OpenBabel-Devel] Hydrogen management bug

[Noel O'Boyle]

 The "M  CHG" line looks dubious. It states that there is a single charge,
a +5 charge on atom 1. What is the source of this SDF file?

Regards,
- Noe

On Tue, 26 Nov 2019 at 12:12, David van der Spoel 
wrote:

> Den 2019-11-26 kl. 13:06, skrev Noel O'Boyle:
> > Hi David,
> >
> > Can you provide the input file?
> Attached, thanks for looking into this.
> >
> > Regards,
> > - Noel
> >
> > On Tue, 26 Nov 2019 at 09:50, David van der Spoel  > <mailto:sp...@xray.bmc.uu.se>> wrote:
> >
> > Den 2019-11-26 kl. 10:12, skrev Noel O'Boyle:
> >  > An SDF file describes the number of hydrogens on each atom. Open
> > Babel
> >  > is neither adding nor removing them. AddHydrogens() is just
> > making them
> >  > explicit.
> > Unfortunately, no. The structure below has 7 hydrogens and one charge
> > but obprop adds one H and 4 (!) charges.
> >
> > % obprop 2-aminoguanidinium.sdf
> > name 2-aminoguanidinium.sdf 1
> > formula  CH8N4+
> >
> >
> >
> >
> >
> >OpenBabel11261907103D
> >
> >12 11  0  0  0  0  0  0  0  0999 V2000
> >  -1.5988   -0.61390.0135 N   0  0  0  0  0  0  0  0  0  0
> 0  0
> >  -0.46551.3957   -0.0077 N   0  0  0  0  0  0  0  0  0  0
> 0  0
> >   0.7405   -0.61230.0118 N   0  0  0  0  0  0  0  0  0  0
> 0  0
> >   1.93920.11530.0724 N   0  0  0  0  0  0  0  0  0  0
> 0  0
> >  -0.44810.06070.0074 C   0  0  0  0  0  0  0  0  0  0
> 0  0
> >  -1.6144   -1.62500.0385 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> >  -2.4894   -0.13450.0041 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> >  -1.31861.9349   -0.0175 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> >   0.41731.8753   -0.1389 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> >   1.96960.65690.9451 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> >   2.7365   -0.53220.1048 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> >   0.8109   -1.6139   -0.1611 H   0  0  0  0  0  0  0  0  0  0
> 0  0
> > 1  6  1  0  0  0  0
> > 2  8  1  0  0  0  0
> > 4  3  1  0  0  0  0
> > 4 11  1  0  0  0  0
> > 4 10  1  0  0  0  0
> > 5  1  1  0  0  0  0
> > 5  2  1  0  0  0  0
> > 5  3  1  0  0  0  0
> > 7  1  1  0  0  0  0
> > 9  2  1  0  0  0  0
> >12  3  1  0  0  0  0
> > M  CHG  1   1   5
> > M  END
> >
> >  >
> >  > Regards,
> >  > - Noel
> >  >
> >  > On Tue, 26 Nov 2019 at 06:50, David van der Spoel
> > mailto:sp...@xray.bmc.uu.se>
> >  > <mailto:sp...@xray.bmc.uu.se <mailto:sp...@xray.bmc.uu.se>>>
> wrote:
> >  >
> >  > Hi,
> >  >
> >  > I was trying to use obprop on an SDF file, but found out that
> > it adds
> >  > one hydrogen to my compound that should not be there. I then
> > went to
> >  > look at the code and removed these two lines
> >  > if (!mol.HasHydrogensAdded())
> >  >   mol.AddHydrogens();
> >  > recompiled and installed.
> >  > Lo and behold, the bug is still there! That is, upon reading
> > an SDF
> >  > file
> >  > the library already adds a hydrogen that shouldn't be there.
> >  >
> >  > What to do about this?
> >  > Replace
> >  > conv.Read(, );
> >  > by a new call
> >  > conv.ReadAndDoNotModifyMyCompound(, );
> >  >
> >  > Other suggestions?
> >  >
> >  > --
> >  > David van der Spoel, Ph.D., Professor of Biology
> >  > Head of Department, Cell & Molecular Biology, Uppsala
> University.
> >  > Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> >  > http://www.icm.uu.se
> >  >
> >  >
> >  > ___
> >  > OpenBabel-Devel mailing list
> >  > OpenBabel-Devel@lists.sourceforge.net
> > <mailto:OpenBabel-Devel@lists.sourceforge.net>
> >  > <mailto:OpenBabel-Devel@lists.sourceforge.net
> > <mailto:OpenBabel-De

Re: [OpenBabel-Devel] Hydrogen management bug

[Noel O'Boyle]

Hi David,

Can you provide the input file?

Regards,
- Noel

On Tue, 26 Nov 2019 at 09:50, David van der Spoel 
wrote:

> Den 2019-11-26 kl. 10:12, skrev Noel O'Boyle:
> > An SDF file describes the number of hydrogens on each atom. Open Babel
> > is neither adding nor removing them. AddHydrogens() is just making them
> > explicit.
> Unfortunately, no. The structure below has 7 hydrogens and one charge
> but obprop adds one H and 4 (!) charges.
>
> % obprop 2-aminoguanidinium.sdf
> name 2-aminoguanidinium.sdf 1
> formula  CH8N4+
>
>
>
>
>
>   OpenBabel11261907103D
>
>   12 11  0  0  0  0  0  0  0  0999 V2000
> -1.5988   -0.61390.0135 N   0  0  0  0  0  0  0  0  0  0  0  0
> -0.46551.3957   -0.0077 N   0  0  0  0  0  0  0  0  0  0  0  0
>  0.7405   -0.61230.0118 N   0  0  0  0  0  0  0  0  0  0  0  0
>  1.93920.11530.0724 N   0  0  0  0  0  0  0  0  0  0  0  0
> -0.44810.06070.0074 C   0  0  0  0  0  0  0  0  0  0  0  0
> -1.6144   -1.62500.0385 H   0  0  0  0  0  0  0  0  0  0  0  0
> -2.4894   -0.13450.0041 H   0  0  0  0  0  0  0  0  0  0  0  0
> -1.31861.9349   -0.0175 H   0  0  0  0  0  0  0  0  0  0  0  0
>  0.41731.8753   -0.1389 H   0  0  0  0  0  0  0  0  0  0  0  0
>  1.96960.65690.9451 H   0  0  0  0  0  0  0  0  0  0  0  0
>  2.7365   -0.53220.1048 H   0  0  0  0  0  0  0  0  0  0  0  0
>  0.8109   -1.6139   -0.1611 H   0  0  0  0  0  0  0  0  0  0  0  0
>1  6  1  0  0  0  0
>2  8  1  0  0  0  0
>4  3  1  0  0  0  0
>4 11  1  0  0  0  0
>4 10  1  0  0  0  0
>5  1  1  0  0  0  0
>5  2  1  0  0  0  0
>5  3  1  0  0  0  0
>7  1  1  0  0  0  0
>9  2  1  0  0  0  0
>   12  3  1  0  0  0  0
> M  CHG  1   1   5
> M  END
>
> >
> > Regards,
> > - Noel
> >
> > On Tue, 26 Nov 2019 at 06:50, David van der Spoel  > <mailto:sp...@xray.bmc.uu.se>> wrote:
> >
> > Hi,
> >
> > I was trying to use obprop on an SDF file, but found out that it adds
> > one hydrogen to my compound that should not be there. I then went to
> > look at the code and removed these two lines
> > if (!mol.HasHydrogensAdded())
> >   mol.AddHydrogens();
> > recompiled and installed.
> > Lo and behold, the bug is still there! That is, upon reading an SDF
> > file
> > the library already adds a hydrogen that shouldn't be there.
> >
> > What to do about this?
> > Replace
> > conv.Read(, );
> > by a new call
> > conv.ReadAndDoNotModifyMyCompound(, );
> >
> > Other suggestions?
> >
> > --
> > David van der Spoel, Ph.D., Professor of Biology
> > Head of Department, Cell & Molecular Biology, Uppsala University.
> > Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> > http://www.icm.uu.se
> >
> >
> > ___
> > OpenBabel-Devel mailing list
> > OpenBabel-Devel@lists.sourceforge.net
> > <mailto:OpenBabel-Devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> >
>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> http://www.icm.uu.se
>
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] [AMBER] PDB CONECT issues with OpenBabel 3.0 and antechamber from Elvis Martis on 2019-10-10 (Amber Archive Oct 2019)

[Noel O'Boyle]

For the record...

http://archive.ambermd.org/201910/0141.html
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] ANNOUNCE: Open Babel 3.0.0 Released

[Noel O'Boyle]

And a big thanks to Geoff for pulling it all together. Hip hip
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0 release?

[Noel O'Boyle]

No worries. Just checking. There's no hurry.

On Wed, 23 Oct 2019, 16:31 Geoffrey Hutchison, 
wrote:

> \Are we good to go? Or are you waiting on me for something? I think I've
> done all I can.
>
>
> I've just been busy, but I'll send out an announcement about the release
> today.
>
> -Geoff
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0 release?

[Noel O'Boyle]

Are we good to go? Or are you waiting on me for something? I think I've
done all I can.

On Tue, 15 Oct 2019, 21:43 Noel O'Boyle,  wrote:

> Ok - I've managed to get the docs and API docs up on openbabel.github.io
> at:
> https://openbabel.github.io/docs/3.0/index.html
> and
> https://openbabel.github.io/api/3.0/index.shtml
>
> Server-side includes don't work on GitHub and so I removed the header and
> footer in the doxygen as described above. This at least gives us the
> defaults. I think that there might be some other way to customise it if we
> want.
>
> Last thing to do is update the links from the Mediawiki install page to
> point to the new docs. But it's getting late
>
> - Noel
>
> On Thu, 10 Oct 2019 at 21:12, Noel O'Boyle  wrote:
>
>> As separately emailed, I've had trouble getting the GitHub pages suite to
>> build and deploy, but I've uploaded the docs there and you can copy to
>> openbabel.org.
>>
>> Since I can't currently depoly to GH pages, could you rebuild the API
>> docs and deploy to your site? Personally, I would make the following
>> changes:
>>
>> -HTML_HEADER= doc/api-header.html
>> +HTML_HEADER= # doc/api-header.html
>>
>> -HTML_FOOTER= doc/api-footer.html
>> +HTML_FOOTER= # doc/api-footer.html
>>
>> on the basis that the closer we are to vanilla doxygen the less
>> maintenance we have to do. I haven't checked these changes in.
>>
>> Regards,
>> - Noel
>>
>> On Wed, 9 Oct 2019 at 01:24, Geoffrey Hutchison <
>> geoff.hutchi...@gmail.com> wrote:
>>
>>> I was thinking about uploading the docs to the github pages site. You
>>> could redirect from openbabel.org/docs when it's ready. I could do the
>>> same for the API docs.
>>>
>>>
>>> Yes - fairly soon I'd like to replace the MediaWiki site with the GitHub
>>> pages version - just haven't had the time to finish. Certainly feel free to
>>> push the new docs to GitHub and I'll be happy to make them part of the
>>> migration.
>>>
>>> -Geoff
>>>
>>>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Algorithm for FF atomtypes

[Noel O'Boyle]

Does your pdb file have hydrogens? If not, even more guessing. Gaussian
files have all the atoms at least.

On Fri, 18 Oct 2019, 19:54 David van der Spoel, 
wrote:

> Den 2019-10-18 kl. 20:37, skrev Noel O'Boyle:
> > With pdb files we have to guess the bond orders. With sdf files, we
> > don't. There shouldn't be any other difference.
>
> How about Gaussian log files? It works with those as well.
> Somehow there bond orders are derived correctly as well although no such
> information is extracted from the log files.
> >
> > On Fri, 18 Oct 2019, 18:52 David van der Spoel,  > <mailto:sp...@xray.bmc.uu.se>> wrote:
> >
> > Hi,
> >
> > it seems that the algorithm for determining bonds and atomtypes
> depends
> > on the input file, is that correct?
> > When I run
> >
> > obenergy -ff GAFF file.pdb
> > I get different bonds then when I run
> > obenergy -ff GAFF file.sdf
> >
> > Since the atomtyping is done based on smarts I wonder whether
> different
> > algorithms are used for generating smarts depending on the input
> file?
> >
> > Alternatively, tips for debugging this, where to look in the code,
> > would
> > be appreciated.
> >
> > Cheers,
> > --
> > David van der Spoel, Ph.D., Professor of Biology
> > Head of Department, Cell & Molecular Biology, Uppsala University.
> > Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> > http://www.icm.uu.se
> >
> >
> > ___
> > OpenBabel-Devel mailing list
> > OpenBabel-Devel@lists.sourceforge.net
> > <mailto:OpenBabel-Devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
> >
>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> http://www.icm.uu.se
>
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Algorithm for FF atomtypes

[Noel O'Boyle]

With pdb files we have to guess the bond orders. With sdf files, we don't.
There shouldn't be any other difference.

On Fri, 18 Oct 2019, 18:52 David van der Spoel, 
wrote:

> Hi,
>
> it seems that the algorithm for determining bonds and atomtypes depends
> on the input file, is that correct?
> When I run
>
> obenergy -ff GAFF file.pdb
> I get different bonds then when I run
> obenergy -ff GAFF file.sdf
>
> Since the atomtyping is done based on smarts I wonder whether different
> algorithms are used for generating smarts depending on the input file?
>
> Alternatively, tips for debugging this, where to look in the code, would
> be appreciated.
>
> Cheers,
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> http://www.icm.uu.se
>
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0 release?

[Noel O'Boyle]

Ok - I've managed to get the docs and API docs up on openbabel.github.io at:
https://openbabel.github.io/docs/3.0/index.html
and
https://openbabel.github.io/api/3.0/index.shtml

Server-side includes don't work on GitHub and so I removed the header and
footer in the doxygen as described above. This at least gives us the
defaults. I think that there might be some other way to customise it if we
want.

Last thing to do is update the links from the Mediawiki install page to
point to the new docs. But it's getting late

- Noel

On Thu, 10 Oct 2019 at 21:12, Noel O'Boyle  wrote:

> As separately emailed, I've had trouble getting the GitHub pages suite to
> build and deploy, but I've uploaded the docs there and you can copy to
> openbabel.org.
>
> Since I can't currently depoly to GH pages, could you rebuild the API docs
> and deploy to your site? Personally, I would make the following changes:
>
> -HTML_HEADER= doc/api-header.html
> +HTML_HEADER= # doc/api-header.html
>
> -HTML_FOOTER= doc/api-footer.html
> +HTML_FOOTER= # doc/api-footer.html
>
> on the basis that the closer we are to vanilla doxygen the less
> maintenance we have to do. I haven't checked these changes in.
>
> Regards,
> - Noel
>
> On Wed, 9 Oct 2019 at 01:24, Geoffrey Hutchison 
> wrote:
>
>> I was thinking about uploading the docs to the github pages site. You
>> could redirect from openbabel.org/docs when it's ready. I could do the
>> same for the API docs.
>>
>>
>> Yes - fairly soon I'd like to replace the MediaWiki site with the GitHub
>> pages version - just haven't had the time to finish. Certainly feel free to
>> push the new docs to GitHub and I'll be happy to make them part of the
>> migration.
>>
>> -Geoff
>>
>>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0 release?

[Noel O'Boyle]

As separately emailed, I've had trouble getting the GitHub pages suite to
build and deploy, but I've uploaded the docs there and you can copy to
openbabel.org.

Since I can't currently depoly to GH pages, could you rebuild the API docs
and deploy to your site? Personally, I would make the following changes:

-HTML_HEADER= doc/api-header.html
+HTML_HEADER= # doc/api-header.html

-HTML_FOOTER= doc/api-footer.html
+HTML_FOOTER= # doc/api-footer.html

on the basis that the closer we are to vanilla doxygen the less
maintenance we have to do. I haven't checked these changes in.

Regards,
- Noel

On Wed, 9 Oct 2019 at 01:24, Geoffrey Hutchison 
wrote:

> I was thinking about uploading the docs to the github pages site. You
> could redirect from openbabel.org/docs when it's ready. I could do the
> same for the API docs.
>
>
> Yes - fairly soon I'd like to replace the MediaWiki site with the GitHub
> pages version - just haven't had the time to finish. Certainly feel free to
> push the new docs to GitHub and I'll be happy to make them part of the
> migration.
>
> -Geoff
>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0 release?

[Noel O'Boyle]

I've attached the binaries to the draft release, and I think the Python
binaries are ready to go.

I was thinking about uploading the docs to the github pages site. You could
redirect from openbabel.org/docs when it's ready. I could do the same for
the API docs.

- Noel

On Sun, 6 Oct 2019 at 03:44, Geoffrey Hutchison 
wrote:

> Can you leave a week between the tagging and the announcement? It's not
> just the Windows binaries but going around updating the download links,
> release notes, etc. Hopefully our conda wizards will also have time to
> build things in this timeframe too.
>
>
> Sure. Let's target Oct. 14th for the release announcement and I'll tag on
> Monday, Oct. 7th.
>
> I have a pull request with final tasks:
> https://github.com/openbabel/openbabel/pull/2052
>
> -Geoff
>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0 release?

[Noel O'Boyle]

Let's do it.

Can you leave a week between the tagging and the announcement? It's not
just the Windows binaries but going around updating the download links,
release notes, etc. Hopefully our conda wizards will also have time to
build things in this timeframe too.

I note in passing that I'm in the process of updating the file format docs,
but this can wait now for 3.0.1.

- Noel

On Fri, 4 Oct 2019 at 20:57, Geoffrey Hutchison 
wrote:

> Well, it's the start of October, so we missed our self-imposed deadline to
> get 3.0 out the door by the end of September.
>
> I think I have all the source packaging issues sorted out. OTOH, I don't
> currently have a way to make Windows binaries.
>
> Should I tag a 3.0 release so we get it out the door while we get the
> Windows binaries together?
>
> Thoughts? It's been so long that I think it's worth getting this out, even
> if we need a 3.0.1 or 3.0.2 fairly soon - and then aim for early 2020 for a
> 3.1 release.
>
> -Geoff
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Docker files...

[Noel O'Boyle]

Centos is binary compatible AFAIK.

On Tue, 17 Sep 2019, 16:19 Patrick Lorton,  wrote:

> I've not been able to google a solution around redhat docker images
> needing a subscription to install any packages, something which I'm not
> really sure how to procure for public use in a github open source project.
> If anyone more RedHat aware than myself has a suggestion, that'd be great.
> Is CentOS 7 close enough do we think?
>
> Pat
>
> On Fri, Sep 13, 2019 at 12:19 PM Patrick Lorton  wrote:
>
>> OK  - sounds good, I've not messed with Red Hat base docker images
>> before, but from googling, it doesn't sound bad.  I'll probably do CentOS 7
>> in addition to these, as it should be trivial and also worth testing.
>>
>> Pat
>>
>> On Fri, Sep 13, 2019 at 12:07 PM Geoffrey Hutchison <
>> geoff.hutchi...@gmail.com> wrote:
>>
>>> Since I don't use Linux, I'm a bit less clear on versions, but I'd
>>> suggest
>>>
>>> - Ubuntu LTS (18.04)
>>> - RHEL LTS 7 maybe?
>>> - Debian 10
>>>
>>> I mean, that would cover common DEB and RPM packages - IMHO let's start
>>> from there and people can add others as desired.
>>>
>>> Thanks,
>>> -Geoff
>>>
>>> ---
>>> Prof. Geoffrey Hutchison
>>> Department of Chemistry
>>> University of Pittsburgh
>>> tel: (412) 648-0492
>>> email: geo...@pitt.edu 
>>> twitter: @ghutchis
>>> web: https://hutchison.chem.pitt.edu/
>>>
>>> On Sep 13, 2019, at 10:02 AM, Patrick Lorton  wrote:
>>>
>>> Hi Geoff - is there a list of linux distro's/versions that'd be most
>>> useful to provide docker files for?  I think I'm going to try to put
>>> something together this weekend but it'd be great if I had a starting point
>>> to target.
>>>
>>> Pat
>>>
>>>
>>>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] maeparser depends on boost iostreams, can openbabel use it?

[Noel O'Boyle]

Just to flag up our first Boost bug report:
https://github.com/openbabel/openbabel/issues/2033

Help would be much appreciated from those with more experience of Boost.

- Noel

On Tue, 11 Jun 2019 at 22:24, Patrick Lorton  wrote:

> Thanks all for the lively conversation.  I've updated the pull request to
> check for boost and only build maeparser if it's available (printing to the
> user saying it's skipping maeparser if it's not available).  I'll probably
> ping a few package maintainers about making sure to add a boost requirement
> when/if this is eventually released.
>
> Pat
>
> On Tue, Jun 11, 2019 at 1:39 PM Koes, David  wrote:
>
>> I agree with Geoff for all the reasons listed. Not being able to use
>> boost is a constant annoyance.  Making any boost dependent features
>> conditional on boost available in cmake seems like a great compromise that
>> will provide the feature to 99% of users while imposing a small burden on
>> the contributor (but less of a burden than having to reimplement boost
>> features).
>>
>> I would like the policy to change from “don’t use boost” to “if you use
>> boost, make sure compilation of your code is guarded in cmake”.
>>
>> David Koes
>>
>> Assistant Professor
>> Computational & Systems Biology
>> University of Pittsburgh
>>
>>
>> On Jun 11, 2019, at 10:14 AM, Geoffrey Hutchison <
>> geoff.hutchi...@gmail.com> wrote:
>>
>> To start out, I'll emphasize that OB has been a default package on
>> several intentionally slow-to-upgrade distros. I'm not surprised to access
>> new supercomputing resources to find Open Babel 2.3.2 or something
>> similarly old. As a result, I do think backwards compatibility for
>> compilers is important.
>>
>> On Jun 11, 2019, at 5:32 AM, Noel O'Boyle  wrote:
>> Well, personally, I don't want that dependency. It would mean dropping
>> support for particular legacy OSes, where Open Babel has compiled without
>> trouble until now (similarly the CXX11 requrest)
>>
>>
>> Perhaps package maintainers can chime in, but IIRC that C++11 was
>> supported back in GCC-4.8.0 from 2013. I don't personally see a problem
>> with that going forward.
>>
>> Turning it around, is it reasonable to add a requirement for Boost just
>> to read in a particular file format? I'm happy to work with you to remove
>> Boost from your codebase if that would help.
>>
>>
>> I mentioned this to Patrick because we have plenty of formats that are
>> turned on or off based on build support (XML, JSON, Eigen, Cairo, etc.)
>>
>> My personal opinion would be to have a Cmake test for Boost and compile
>> the maeparser code conditional on that. At one point we had a boost check
>> (for shared_ptr support) and it's definitely how things are organized for
>> formats:
>>
>> if(MSVC OR HAVE_REGEX_H)
>> …
>>
>> endif(MSVC OR HAVE_REGEX_H)
>>
>> if(WITH_JSON)
>>
>> (etc).
>>
>> From Patrick:
>>
>> my worry there is that package maintainers would default to leaving it
>> off and not add boost as a requirement, effectively disabling this feature
>> for most users.
>>
>>
>> I don't think we can control what package maintainers do. But if you
>> think package maintainers are going to ignore features with Boost, that
>> tells me a lot..
>>
>> For now, I'm fine with Boost as an optional dependency for MAE
>> compilation.
>>
>> -Geoff
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>>
>> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenbabel-develdata=02%7C01%7Cdkoes%40pitt.edu%7C68edfea1b7e54f7b0e5408d6ee771c1c%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1%7C0%7C636958592679903209sdata=aMfq4jNyCS1oGFTgR4uBbhmMrw8NiJKeUB2f3b8vLe4%3Dreserved=0
>>
>>
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] 3.0.0alpha 1

[Noel O'Boyle]

A good place to put those scripts would be the repo I've just made:
https://github.com/openbabel/maintenance

Should I tag the source differently next Monday? Also, I think I messed up
the release digits in the Cmake file. I should have had .0a1 but instead
have .a1.

I'll upload the Windows binaries which for the most part are there.

I'm thinking about including Inchi 1.05 over the next week. Matt Swain
suggested automatic download and install back in June. But at this point
I'm thinking to keep it simple and just do as we are already. There are
sufficient changes that this is already a bit of work.

-Noel


On Sat, 14 Sep 2019, 15:04 Geoffrey Hutchison, 
wrote:

> Yesterday, I dusted off the "make a source release" script on my desktop..
> to find that it's been long enough that my new desktop doesn't have all the
> various compilers to check PHP, C#, etc.
>
> I also discovered that GitHub is annoying about naming files matching
> their auto-generated .tar.gz and .zip. Naturally, our source release has a
> variety of the SWIG-generated bindings that are not stored in Git.
>
> There is a release tag:
> https://github.com/openbabel/openbabel/releases/tag/openbabel-3-0-0a1
>
> This does not include the various commits made since Noel tagged on Monday.
>
> Here are my working notes - I will have a modified shell script whipped up
> next week:
> https://gist.github.com/ghutchis/c33928316217730006790e6724993e26
>
> -Geoff
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Source release

[Noel O'Boyle]

Automating would be good. I have a script that should be automatic in
theory...I just need it to work once. Almost there.

On Thu, 12 Sep 2019 at 15:45, Geoffrey Hutchison 
wrote:

> Yes, I can make a source release tomorrow.
>
> One way or another, I'd like to have either the AppVeyor build or a
> Docker to make the Windows binaries. There are some scripts around for
> making "continuous" binaries available from Travis or AppVeyor, which
> seems like a good step forward.
>
> On Thu, Sep 12, 2019 at 10:13 AM Noel O'Boyle 
> wrote:
> >
> > Hi Geoff,
> >
> > Are you going to be able to look after the source release tomorrow? Or
> will I? Either way, it would be good to have a write-up of the steps
> involved.
> >
> > I've updated the release notes and am currently struggling through
> updating my build toolchain on Windows. Will I have some binaries for
> tomorrow? I don't know. But there's always next week...
> >
> > Regards,
> > - Noel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Source release

[Noel O'Boyle]

Hi Geoff,

Are you going to be able to look after the source release tomorrow? Or will
I? Either way, it would be good to have a write-up of the steps involved.

I've updated the release notes and am currently struggling through updating
my build toolchain on Windows. Will I have some binaries for tomorrow? I
don't know. But there's always next week...

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Open Babel 3.0.0a1 tagged

[Noel O'Boyle]

Hi all,

I've tagged the 3.0.0a1 release ("git checkout openbabel-3-0-0a1" I think
will work), and a GitHub release will appear on Friday, hopefully alongside
other releases such as Snaps, Python bindings, Windows executables, Docker
build scripts, etc. Or more likely, I'll find out that I have to make some
commits to get these to work and so they will await the a2 release.

I've created a repo openbabel/maintenance for any notes or scripts useful
in creating a release or updating documentation (etc.). Feel free to
request direct access if useful.

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release Schedule

[Noel O'Boyle]

Absolutely. That'd be great. I'll make a new repo for all distribution (and
maintenance) related scripts/recipes (if there isn't already one) so that
we have them all in one place.

On Fri, 6 Sep 2019 at 14:53, Patrick Lorton  wrote:

> Hi Noel - I'd be happy to put together some Docker recipes for the most
> important platforms and all their versions OpenBabel is supposed to
> support.  If that's done then anyone with docker installed on their machine
> could just run single commands to confirm that OpenBabel builds and tests
> pass on each platform with the appropriate dependencies.  Does that sound
> like something you'd be interested in?
>
> As an example, I have a recipe here for RDKit+GPUSim on Ubuntu with Cuda
> drivers:
> https://github.com/schrodinger/gpusimilarity/blob/master/docker/Dockerfile
>
> That pulls down RDKit and builds it on Ubuntu - in this case to be used
> with GPUSim, but you can see it'd be trivial to just run the tests at the
> end.  This is how I guarantee my changes on GPUSim are working on Ubuntu
> (the most popular platform for it) even when I do all my dev on Arch.
>
> Pat
>
> On Fri, Sep 6, 2019 at 9:27 AM Noel O'Boyle  wrote:
>
>> Hi all,
>>
>> Geoff asked me to bring up the discussion of a release schedule for OB
>> 3.0. It's been so long since the last release, that it's become painful for
>> us to do a release, which is a bit of a vicious cycle as you can imagine.
>> So
>>
>> I have some time to do this now (with help I hope!) so I'm going to
>> randomly suggest that every Friday until finished, we do a release. Every
>> Monday morning, I'll bump the version and tag that git revision, and
>> between then and end of Friday we'll try and get all parts of the release
>> done.
>>
>> So next Friday we do a release - it might be 3.0a, and the release notes
>> out of date, Python 2 unsupported and conda only working on Linux. And the
>> following Friday - it might be 3.0a2, but most parts of the release have
>> been automated and updated. And so on, until we have 3.0 - the goal is the
>> last Friday of September.
>>
>> The reason we need to do this is that we need to start oiling our release
>> procedures, and get things automated (as much as possible). Get release
>> scripts together - check them in somewhere - and make it so that creating a
>> release is not painful. Frequent releases are a great spur to doing this
>> even if only alpha releases.
>>
>> With this in mind, I'm going to suggest that we feature freeze and focus
>> on release blockers. We shouldn't be dogmatic (e.g. I note that I have
>> already agreed to review/merge David Koes mega PR) but we should try to
>> avoid making the documentation out-of-date during the release procedure. If
>> everything gets super automated, it will not be difficult to do another
>> point release in 3 or 6 months so no-one should panic that their work will
>> have to wait for another 3 years.
>>
>> So if people want to help we will need testers for the conda packages,
>> the snap packages, the Python binaries, etc., etc. Does it build on Ubuntu?
>> Does it build on Arch? Help updating the documentation would be much
>> appreciated - you can do this directly on the github repo. If you want to
>> help but don't know how/where, just email the list - there are many things
>> that we would do if we had more time, so don't hold back.
>>
>> Geoff - does this sound reasonable? I can send to openbabel-discuss also
>> if it's okay.
>>
>> Regards,
>>Noel
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Release Schedule

[Noel O'Boyle]

Hi all,

Geoff asked me to bring up the discussion of a release schedule for OB 3.0.
It's been so long since the last release, that it's become painful for us
to do a release, which is a bit of a vicious cycle as you can imagine.
So

I have some time to do this now (with help I hope!) so I'm going to
randomly suggest that every Friday until finished, we do a release. Every
Monday morning, I'll bump the version and tag that git revision, and
between then and end of Friday we'll try and get all parts of the release
done.

So next Friday we do a release - it might be 3.0a, and the release notes
out of date, Python 2 unsupported and conda only working on Linux. And the
following Friday - it might be 3.0a2, but most parts of the release have
been automated and updated. And so on, until we have 3.0 - the goal is the
last Friday of September.

The reason we need to do this is that we need to start oiling our release
procedures, and get things automated (as much as possible). Get release
scripts together - check them in somewhere - and make it so that creating a
release is not painful. Frequent releases are a great spur to doing this
even if only alpha releases.

With this in mind, I'm going to suggest that we feature freeze and focus on
release blockers. We shouldn't be dogmatic (e.g. I note that I have already
agreed to review/merge David Koes mega PR) but we should try to avoid
making the documentation out-of-date during the release procedure. If
everything gets super automated, it will not be difficult to do another
point release in 3 or 6 months so no-one should panic that their work will
have to wait for another 3 years.

So if people want to help we will need testers for the conda packages, the
snap packages, the Python binaries, etc., etc. Does it build on Ubuntu?
Does it build on Arch? Help updating the documentation would be much
appreciated - you can do this directly on the github repo. If you want to
help but don't know how/where, just email the list - there are many things
that we would do if we had more time, so don't hold back.

Geoff - does this sound reasonable? I can send to openbabel-discuss also if
it's okay.

Regards,
   Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] PDB files with multiple bonds via CONECT

[Noel O'Boyle]

I'm on the fence. Usually I'd say avoid extensions by default, but this
looks like a common extension that preserves information. But I can't
really say as I don't deal with PDB files. But if you do go ahead with
this, it's important that there is an option to turn it off in case it does
cause problems for anyone.

On Mon, 29 Jul 2019 at 22:01, David Koes  wrote:

> Thanks Geoff - I've been meaning to write to the list about this, but
> haven't made the time.  But I'll make the time now
> since there are other facets of this pull request that deserve discussion.
>
> My goal in putting the pull request together was to make it so that
> openbabel doesn't break molecules.  Many of us use
> openbabel extensively to convert between formats as part of our workflows,
> and I think it is eminently reasonable to
> expect the molecule that comes out is the same as the one you put in.
>
> Towards this end, I put together a set of 13,997 ligands extracted from
> the PDB (getting the SDF file, which is more
> nicely processed than the raw PDB).  I then wrote round-tripping code that
> makes sure the molecule stays the same when
> converting between file formats.  There were initially thousands of
> failures and now there are none.  You can see the
> pull request for the various minor bug fixes (particularly to bond
> typing), but the main thing was adding additional
> information to file formats.
>
> PDB
> By default bond orders are now output using multiple CONECT records.
> There is an option to revert to single CONECT
> records.  I don't think this is technically a violation of the standard
> and preserves essential information.  It's also
> a convention that several other packages (e.g. RDKit) use.
>
> Mol2
> Formal charges are output using UNIT_ATOM_ATTR records.  This is part of
> the standard and there is an option to disable
> this output.
>
> SDF
> Reading the CTFile Formats document (
> https://www.daylight.com/meetings/mug05/Kappler/ctfile.pdf) I do not see
> how
> openbabel's interpretation of the atom alias record is correct.  openbabel
> treats it like a group abbreviation or
> substitution (the atom is replaced by the functional group named in the
> alias record).  But it really seems like it
> should just be specifying an alternate name for the atom, and this is
> exactly what SDF files from the PDB use it for.
> Treating the atom name as a function group replacement causes serious
> issues with the atom name happens to equal a
> functional group name.  Nonetheless, to maintain as much backwards
> compatibility as possible, I've made it so that
> replacement still happens if the atom is a wildcard type.  I have not
> included an option for the old behavior since I
> see no evidence it is standards compliant.
>
> Overall, there are some breaks from previous behavior, but the 3.0
> release, which is breaking backwards compatibility in
> multiple ways, is the ideal time to implement these relatively minor
> changes.  I don't think you will ever be able to
> fully trust openbabel converting between popular formats without changes
> like these (bond order and charge information
> is too important).
>
> Thanks,
>
> David Koes
>
> Assistant Professor
> Computational & Systems Biology
> University of Pittsburgh
>
> On 7/29/19 4:11 PM, Geoffrey Hutchison wrote:
> > David Koes has contributed a pull request that fixes a bunch of file
> handling errors via round-trip testing.
> >
> > One thing he's implemented is to bring back writing PDB files with
> multiple bond orders via repeated CONECT records.
> >
> > Before I consider the rest of the patch, I want to know opinions on
> this. It's been a few years since OB reverted to "standard" PDB output and
> omitted only one CONECT per bond connection. This matches the practice of
> the PDB itself, although the "bond order" practice is fairly wide-spread.
> >
> > David feels strongly that OB should default to write files with bond
> order information.
> >
> > I can't find the threads of previous discussion, which suggests some of
> it was in the SourceForge bug tracker - I can't find anything pro or con
> from that discussion, only that it was eventually decided to stick with one
> CONECT per bond.
> > - Do you favor single CONECT records?
> > - Do you favor bond order information?
> > - What do you feel are pro or cons?
> >
> > I'd like an open discussion. If it's possible, I know many people expect
> PDB files to support bond orders.
> >
> > -Geoff
> >
>
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Stereochemistry check using InChIKey

[Noel O'Boyle]

If you use canonical SMILES instead of the InChI to evaluate changes in
stereo, do the results change? If you use canonical SMILES, you will also
be able to manually verify what's different.

- Noel

On Fri, 21 Jun 2019 at 09:05, Naruki Yoshikawa 
wrote:

> Hi all,
>
> I've been developing a new distance geometry method these days.
> https://github.com/openbabel/openbabel/pull/1875
>
> I generated SMILES from experimental structures and predict a 3D
> structure from the SMILES.
> I compare InChIKey of experimental structure and predicted structure
> to evaluate stereochemistry correctness.
> The distance geometry function uses
> OBDistanceGeometry::CheckStereoConstraints() to check stereo
> constraints are satisfied.
>
> https://github.com/openbabel/openbabel/blob/528f73fe64376ce8922897748e2879a6d599e7ed/src/distgeom.cpp#L953
> Even though stereo constraints are satisfied judging from this
> function, InChIKey did not match in some molecules.
>
> I prepared test cases here:
>
> https://gist.github.com/n-yoshikawa/00dc043694b539fb5f9340f48fb5d2b0#file-checkstereo-cpp
> This gist includes SDFs predicted from SMILES and they have the above
> problem as shown in result.txt.
>
> Could you suggest possible cause of this problem?
>
> Naruki
>
>
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] maeparser depends on boost iostreams, can openbabel use it?

[Noel O'Boyle]

Well, personally, I don't want that dependency. It would mean dropping
support for particular legacy OSes, where Open Babel has compiled without
trouble until now (similarly the CXX11 requrest). As I see it, users of
Open Babel will see no benefit from us using Boost, but will find it more
difficult to compile.

Turning it around, is it reasonable to add a requirement for Boost just to
read in a particular file format? I'm happy to work with you to remove
Boost from your codebase if that would help.

Regards,
- Noel

On Mon, 10 Jun 2019 at 13:45, Patrick Lorton  wrote:

> Hello all - I just put together a pull request
> to add maestro file
> parsing support (using maeparser
> ) to OpenBabel.  Geoff pointed
> out in the pull request that Boost is not currently a requirement of
> OpenBabel, and that it was not clear if it's a good idea to make it one.
>
> I'm curious what the current opinions would be towards making Boost a
> requirement of OpenBabel?  RDKit has had a semi-optional Boost requirement
> for a while (including for its use of maeparser now), so OpenBabel wouldn't
> be alone amongst Chemistry packages.
>
> As long as someone's not using cutting edge Boost features, it seems a
> guarantee for package managers to have working versions of Boost available
> (including Conda of course).
>
> There's some 'in the middle' options: detecting whether Boost is already
> installed, and only building Maestro support in if it's already available;
> or having maeparser just off by default and allow people to turn it on
> (also turning Boost requirement on).  I think those options would
> effectively turn maeparser off for the vast majority of users who would be
> using OpenBabel from a package built with minimum dependencies.
>
> I'm personally advocating for adding a default-boost-requirement that
> could be turned off by turning maeparser off, but am of course at the
> service of the project owners :)
>
> Looking forward to any thoughts/discussions,
> Pat
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Removal of babel

[Noel O'Boyle]

Are we going to do this for 3.0? I think we should.

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Atom and bond manipulation

[Noel O'Boyle]

Hey Geoff et al,

The last thing I want to tidy up before 3.0 are the functions I added in
obfunctions.h. These are 3 atom and bond based functions that I didn't want
to just chuck into atom.h and bond.h.

What I'd really like to do is have atommanip.h (or atomfunctions.h,
atomops.h, whatever) that would hold atom based functions that shouldn't
really be in atom.h. And similarly for bond.h. (In theory also for mol.h
but the low-hanging fruit are the atoms and bonds - OB 4.0 can sort out the
mols.) There are a whole bunch of random methods (e.g.
OBAtom::LewisAcidBaseCounts()) that are just slowing down compilation and
hiding the core data-acess methods.

If this is too big a change, that's fine. I'll just sort out the 3 in
obfunctions.h (by chucking them into atom.h ad bond.h) and finish up.
Otherwise, I can write up a list of functions that I'd recommend moving out
as part of a proper proposal.

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Towards a release

[Noel O'Boyle]

>From my point of view, the only required changes before the next release
are those that break the API or change behaviour as they can't be done
thereafter. With this in mind, I'm going to send in a few pull requests for
changes which I think would be good tidy ups (e.g. functions marked as
deprecated since before I joined, or ensuring that all of the flags have
the same getters/setters, or figuring out what to get about a GetValence()
function that doesn't return the valence). These will individually be small
changes, and some may be rejected, but it's now or never.

Regards,
- Noel

On Fri, 8 Mar 2019 at 02:01, Geoffrey Hutchison 
wrote:

> > I have a bit more free time now. Let's work towards a release.
>
> First off, Noel deserves a lot of thanks for pushing a lot of changes for
> 3.0 and keeping things going.
>
> In other words, let's get a list of any remaining critical bugs  and
> push towards a defined release date for 3.0?
> (Speaking of which, if anyone is at ACS Orlando, I'd be happy to see about
> meeting.)
>
> I can see a few pull requests that we should push through and/or discuss:
> - IsElement implemention, make OBElements::Element enum
> https://github.com/openbabel/openbabel/pull/1754
> - WriteString / WriteFile changes
> https://github.com/openbabel/openbabel/pull/1923
> - Refactor Python  https://github.com/openbabel/openbabel/pull/1946
>
> Optional but nice;
> - Periodic boundary conditions (e.g., for UFF)
> https://github.com/openbabel/openbabel/pull/1853
> - Coulomb integrals (e.g., for QEq and other charges)
> https://github.com/openbabel/openbabel/pull/1859
>
> What about bug reports?
> -Geoff
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Towards a release

[Noel O'Boyle]

Hi everyone,

I have a bit more free time now. Let's work towards a release.

Regards,
- Noel
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] OBOp

[Noel O'Boyle]

I presume it's a C++ "static method", what's called a "class method" in
Python. These are methods that don't require an instance of an object, but
that you can call directly. The confusing part is that (in this case) the
return value is an instance of the class.

This approach might seem a bit roundabout, but it's part of the plugin
architecture. We don't know in advance what plugins might be present. The
user can delete some or add their own that we've never seen. So you need to
go looking for a particular plugin when you want it.

Regards,
- Noel

On Wed, 5 Sep 2018 at 17:30, Geoffrey Hutchison 
wrote:

> > In first line (1) I declare a pointer to OBOp type named pOp and what I
> dont
> > understand is what am I really assigning, is OBOP a namespace? and what
> does
> > this line really do?
>
> OBOp is a general C++ class. There are different types of “Op”s that
> perform operations on molecules. This first line tells Open Babel to find
> the “gen2D” operation (to generate a 2D depiction).
>
> > In second line I pass  object to method Do, What does this method
> > really do?
>
> Since the code selected the gen2D operation, it generates 2D coordinates
> for the mol2 object.
>
> Hope that helps,
> -Geoff
>
> ---
> Prof. Geoffrey Hutchison
> Department of Chemistry
> University of Pittsburgh
> tel: (412) 648-0492
> email: geo...@pitt.edu
> twitter: @ghutchis
> web: https://hutchison.chem.pitt.edu/
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] GSoC project completion

[Noel O'Boyle]

Well done. I hope you found the experience useful. It was also good to meet
you at the ACS.

All the best for your future work.

Regards,
- Noel

On Sat, 25 Aug 2018 at 07:27, Naruki Yoshikawa 
wrote:

> Hi everyone,
>
> In April, I introduced my Google Summer of Code project: "Fast, Efficient
> Fragment-Based Coordinate Generation":
> https://summerofcode.withgoogle.com/projects/#5029822145757184
>
> I successfully completed the GSoC project.
> I really appreciate the help from my mentor Geoff Hutchison and this
> mailing list.
>
> If you are interested, you can read my final report at:
>
> https://docs.google.com/document/d/1pvAt8ykIDNs9GWTGVUgjvw4-JyHzykBn13jRKGErW_o/
>
>
> Thanks,
> Naruki
>
> ---
> Naruki Yoshikawa
> Department of Computational Biology and Medical Sciences,
> Graduate School of Frontier Sciences
> The University of Tokyo
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Failing master

[Noel O'Boyle]

Hi Geoff,

It looks like the Clang build is failing on master. If you've a chance, can
you track down what specific merge/commit is causing this? Or am I wrong?

Regards,
- Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Proposal to remove "Unset" functions for flags

[Noel O'Boyle]

May I suggest that we replace Unset functions for flags (e.g.
UnsetAromaticPerceived()), with a parameter to the Set functions (e.g.
SetAromaticPerceived(false))? This is already the case for some of the Set
functions. This would tidy the API a bit, and ensure that we actually have
the ability to both set and unset flags (which wasn't the case for at least
some flags). I think user impact will be minimal.

If we wanted to go further, then we could replace the all of these
functions with just two: SetFlag(bits) and UnsetFlag(bits), where we would
provide an enum for the bits.

Regards,
- Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Implementation of s-type Slater orbitals in open babel

[Noel O'Boyle]

Hi Mohammad,

Just to take a step back, could you describe how users of Open Babel will
benefit from this? That is, what they might use these charges for? I know
that Open Babel already has several charge models, but none are documented
currently, and so I have no clue what to do with them except calculate the
values and write them out.

Regards,
- Noel

On 14 June 2018 at 09:36, Mohammad Mehdi Ghahremanpour <
m.ghahremanp...@hotmail.com> wrote:

> Open Babel developers,
>
> We are planning to implement a library of coulomb integrals for Slater-
> and Gaussian-type charges into open babel.
>
> We have implemented the Slater integrals (analytical solutions) in two
> different versions. The first version uses an arbitrary high precision
> (using the CLN library) that supports 1s to 6s Slater orbitals. The second
> version uses double precision that only supports 1s to 3s orbitals. The CLN
> version is slower than the second version and also makes Open Babel
> dependent on the CLN library, but it has a much higher precision and also
> takes care of 4s and 5s orbitals that we need for Br and I. However, we
> have recently parametrized 3s orbitals for Br and I and our results show
> that this is a good approximation.
>
> Geoff and I have been discussing whether it is better to implement both
> versions and then decide to compile it with or without the CLN library
> using a cmake flag or just implement the
> double precision version that only supports 1s->3s Slater orbitals which
> is more straightforward.
>
> So, what do you think?
>
> Cheers,
> Mohammad
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Invalidation of aromaticity flags

[Noel O'Boyle]

I forgot to say that the background to all of this is that I was writing up
docs describing the handling of aromaticity in Open Babel, and when I got
to the section describing DeleteAtom() I found that the behaviour was not
how I thought.

- Noel

On 14 June 2018 at 07:03, Noel O'Boyle  wrote:

> Hi all,
>
> I've sent in a pull request (https://github.com/openbabel/
> openbabel/pull/1847) regarding to DeleteAtom() and aromaticity, and Geoff
> asked me to bring it up here.
>
> Currently, when you delete an atom (to be exact, it's actually
> Begin/EndModify that I'm changing), the flag that indicates that
> aromaticity is detected is cleared. This means that the reported
> aromaticity on an atom or bond will always be in synch with the molecule's
> current structure.
>
> I propose to change this so that the aromaticity flag on the molecule is
> unaffected by deleting atoms (or indeed by any API call that involves
> Begin/EndModify).
>
> The reason I propose this is:
> (a) to make it obvious how the user can retain the original aromaticity if
> they wish, even after modifying the molecule (this is the main reason).
> With the current behavior, a user would never realise that aromaticity
> information is still present, or that they just need to set that it has
> been perceived (which is counter-intuitive).
> (b) to avoid unneccessary work (e.g.calling DeleteHydrogens should not
> invalidate aromaticity (if it currently does))
>
> I could also argue that it simplifies toolkit behavior a bit (only the
> user can invalidate aromaticity), but that's not really a reason for doing
> this, just a possible silver lining.
>
> I think this is a reasonably safe change because:
> (a) aromaticity is stored on atoms and bonds, rather than involving a data
> structure that retains pointers to atoms or bonds.
> (b) if the user does not wish this behavior, it should be fairly (?)
> obvious that it's happening, and there's a clear fix
>
> Regards,
> - Noel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Invalidation of aromaticity flags

[Noel O'Boyle]

Hi all,

I've sent in a pull request (
https://github.com/openbabel/openbabel/pull/1847) regarding to DeleteAtom()
and aromaticity, and Geoff asked me to bring it up here.

Currently, when you delete an atom (to be exact, it's actually
Begin/EndModify that I'm changing), the flag that indicates that
aromaticity is detected is cleared. This means that the reported
aromaticity on an atom or bond will always be in synch with the molecule's
current structure.

I propose to change this so that the aromaticity flag on the molecule is
unaffected by deleting atoms (or indeed by any API call that involves
Begin/EndModify).

The reason I propose this is:
(a) to make it obvious how the user can retain the original aromaticity if
they wish, even after modifying the molecule (this is the main reason).
With the current behavior, a user would never realise that aromaticity
information is still present, or that they just need to set that it has
been perceived (which is counter-intuitive).
(b) to avoid unneccessary work (e.g.calling DeleteHydrogens should not
invalidate aromaticity (if it currently does))

I could also argue that it simplifies toolkit behavior a bit (only the user
can invalidate aromaticity), but that's not really a reason for doing this,
just a possible silver lining.

I think this is a reasonably safe change because:
(a) aromaticity is stored on atoms and bonds, rather than involving a data
structure that retains pointers to atoms or bonds.
(b) if the user does not wish this behavior, it should be fairly (?)
obvious that it's happening, and there's a clear fix

Regards,
- Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Getting SMILES Atom Order data

[Noel O'Boyle]

Two points to note:
1. If you break a bond, you should increase the implicit H count of the
attached atoms by the bond order. Otherwise you end up with radicals, as
you've seen.
2. If you copy the substructure instead of fragmenting, then the process
may be simpler as there is an option to adjust the H counts automatically.
See my code at
https://baoilleach.blogspot.co.uk/2018/05/when-all-you-want-is-ring.html
and
https://baoilleach.blogspot.co.uk/2018/05/when-all-you-want-is-ring-part-ii.html

- Noel

On 21 May 2018 at 13:41, Naruki Yoshikawa <naruki.yoshik...@gmail.com>
wrote:

> Hi Noel,
>
> I updated the fragmentation code.
> My code is available at https://github.com/n-yoshik
> awa/contributed/blob/master/c%2B%2B/fragments/obfragment.cpp
>
> I enumerated ten most frequent fragments from our data by using this code.
> The result was as follows:
>
> SMILES  percent
>
> [C]1=CC=[C]C=C1 11.1425
>
> [C]1=CC=CC=C1   7.94308
>
> [C]1=CC=C[C]=C1 4.3803
>
> [C]1=CC=[C][C]=C1   2.76544
>
> [C]1=C[C]=[C]C=C1   2.74526
>
> [CH]1[CH][CH][CH]O1 2.12959
>
> [CH]1[CH][CH][CH]O[CH]1 1.87727
>
> [C]1=CC=CC=[C]1 1.77634
>
> [C]1=CC=C[C]=[C]1   1.31207
>
> [C]1=C[C]=[C][C]=C1 1.18086
>
>
> These fragments have some common parts.
> I want to consolidate these into more common fragments.
>
> As Geoff says:
> > Most of these are benzene or other 6-membered aromatic rings.
> > So 8 of them should consolidate to something like ｀c1c1｀ and the
> other two look like 5-membered and 6-membered sugars, which makes sense.
>
> > I think the key problem is that the code is generating radicals (e.g.,
> the [C] pieces.
> > My suggestion would be to take these SMILES fragments, read them in
> again and write out again.
> > But I think Noel has a new way of generating canonical SMILES from
> fragments. I’d suggest posting to the list and asking. Either way would
> consolidate all these strings into c1c1
>
> Do you have any suggestion about generating canonical SMILES from
> fragments or consolidating fragments?
>
> Thanks,
> Naruki
>
> 2018年5月17日(木) 20:45 Noel O'Boyle <baoille...@gmail.com>:
>
>> It was on Github. Here you go: https://github.com/openbabel/o
>> penbabel/pull/1712
>>
>> Are you sure you don't just want the canonical labels? I'm happy to
>> review...
>>
>> On 17 May 2018 at 11:47, Geoffrey Hutchison <geoff.hutchi...@gmail.com>
>> wrote:
>>
>>> Hi Noel,
>>>
>>> I'm working with Naruki, the student with GSoC developing the
>>> fragment-based coordinate generation.
>>>
>>> He's updating my old fragmentation code, which used the SMILES Atom
>>> Order data to canonicalize fragments. I can't find your comments on this,
>>> and I don't remember whether it was in the GitHub tracker or Open Babel
>>> development list.
>>>
>>> Thanks,
>>> -Geoff
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
>> _
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Getting SMILES Atom Order data

[Noel O'Boyle]

It was on Github. Here you go:
https://github.com/openbabel/openbabel/pull/1712

Are you sure you don't just want the canonical labels? I'm happy to
review...

On 17 May 2018 at 11:47, Geoffrey Hutchison 
wrote:

> Hi Noel,
>
> I'm working with Naruki, the student with GSoC developing the
> fragment-based coordinate generation.
>
> He's updating my old fragmentation code, which used the SMILES Atom Order
> data to canonicalize fragments. I can't find your comments on this, and I
> don't remember whether it was in the GitHub tracker or Open Babel
> development list.
>
> Thanks,
> -Geoff
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Need for a stop-gap 2.4.2 release.

[Noel O'Boyle]

Let me know if you need anything from me.

On Fri, 20 Apr 2018, 16:11 Geoffrey Hutchison, 
wrote:

> It's been about 18 months since the release of 2.4.1. While there's a lot
> of progress (thanks mostly to Noel) for 3.0 at the end of the summer, I'd
> like to push for a 2.4.2 release ASAP.
>
> There are some clearly easy bug fixes that can be back-ported to the 2.4.x
> series. If you have particular bugs or better yet, pull requests, please
> let me know.
>
> I'll try to push for a mid-May release.
> -Geoff
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

My recommended procedure would be to write to stdout and capture it.
There's no guarantee that we can write to disk. I can add a line on that...

On 26 April 2018 at 12:06, Koes, David <dk...@pitt.edu> wrote:

> Do you want to have a recommended procedure for tests that write files and
> then need to compare them?  I’m assuming from what you wrote that tests are
> automatically run from the tests/files directory and I think you would want
> to discourage people from cluttering that directory with output files.
>
> David Koes
>
> Assistant Professor
> Computational & Systems Biology
> University of Pittsburgh
>
>
> On Apr 26, 2018, at 2:43 AM, Noel O'Boyle <baoille...@gmail.com> wrote:
>
> Okay, I think it's close to completion. Again, comments welcome...
>
> https://gist.github.com/baoilleach/d9f02fb906e70277f6b4721d63d68b59
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fbaoilleach%2Fd9f02fb906e70277f6b4721d63d68b59=01%7C01%7Cdkoes%40pitt.edu%7C25c77bb7b05044216f3308d5ab410f9b%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1=heUqOf2FPDJWDqShbWBFL79e5SV8cABDBkL%2BhHuu44w%3D=0>
>
> - Noel
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

Okay, I think it's close to completion. Again, comments welcome...

https://gist.github.com/baoilleach/d9f02fb906e70277f6b4721d63d68b59

- Noel

On 25 April 2018 at 13:50, David Koes <dk...@pitt.edu> wrote:

> Missing description of OB_COMPARE (and other asserts?).  Is the idea of
> OB_REQUIRE that it should be used for checks that would indicate there is
> something wrong with the overall test harness because it will end _all_
> tests, not the current one?
>
> Could give one sentence description of run_exec (a helper function that
> passes the contents of its first argument as stdin to the commandline
> specified as the second argument).
>
> Definitely want to know how to add input/output files and properly
> reference them from all three test scenarios.
>
> David Koes
>
> Assistant Professor
> Computational & Systems Biology
> University of Pittsburgh
>
> On 04/25/2018 02:21 AM, Noel O'Boyle wrote:
>
>> (Sorry - previous email was sent by accident)
>>
>> On the topic of documentation, here's what I've got so far:
>> https://gist.github.com/baoilleach/d9f02fb906e70277f6b4721d63d68b59 <
>> https://na01.safelinks.protection.outlook.com/?url=https%
>> 3A%2F%2Fgist.github.com%2Fbaoilleach%2Fd9f02fb906e70277f6b47
>> 21d63d68b59=01%7C01%7Cdkoes%40pitt.edu%7Cf543c3eb2
>> 60b487ad9ad08d5aa74c860%7C9ef9f489e0a04eeb87cc3a526112fd0d%
>> 7C1=gBUFcMEX89RR%2FA95ZIh2w9wzBFTS2grmYxFA2uZMI4Q%3D=0>
>>
>> I still need to add descriptions of how to specify testfiles, and handle
>> exceptions. Apart from that, anything missing or could be explained better?
>>
>> - Noel
>>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] GSoC project introduction - Fast, Efficient Fragment-Based Coordinate Generation

[Noel O'Boyle]

Hi Naruki,

Welcome to the list. I wish you all the best - this would be a great
improvement to Open Babel.

Regards,
- Noel

On 25 April 2018 at 12:18, Naruki Yoshikawa 
wrote:

> Hi everyone,
>
> I am going to work on the project "Fast, Efficient Fragment-Based
> Coordinate Generation"
> https://summerofcode.withgoogle.com/projects/#5029822145757184
> during Google Summer of Code 2018.
> The goal of this project is to implement a fast and efficient method to
> predict 3-D coordinates.
> I'm happy to work with my mentor Geoff Hutchison and the Open Babel
> community.
>
> The first month of GSoC is the Community Bonding period.
> I would like to interact with the Open Babel community.
> Any comments are welcome.
>
>
> Project abstract:
> Chemical information is provided in various formats. Open Babel is a tool
> to convert file formats.
> When we translate a format which does not include 3-D coordinate
> information into a format which requires it, we must predict coordinates.
> Open Babel implements a rule-based coordinate prediction method, but the
> current implementation is problematic.
> It sometimes fails when we treat inorganic and organometallic molecules,
> and by relying on force field geometry optimization,
> it is slower than distance-geometry or fragment-based methods.
>
> This is a proposal to implement a fast and efficient method to calculate
> 3-D coordinates using fragment information.
> Since fragments can decide the position of many atoms at once and minimize
> the need for conformer sampling, this approach is more efficient.
> P. Baldi's paper in 2013 reports that their fragment-based method is more
> accurate and 10 times faster than Open Babel.
> Implementing a better prediction method is beneficial for chemistry and
> leads to new discoveries in the field of drug design.
>
>
> Thanks,
> Naruki
>
> ---
> Naruki Yoshikawa
> Department of Computational Biology and Medical Sciences,
> Graduate School of Frontier Sciences
> The University of Tokyo
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

(Sorry - previous email was sent by accident)

On the topic of documentation, here's what I've got so far:
https://gist.github.com/baoilleach/d9f02fb906e70277f6b4721d63d68b59

I still need to add descriptions of how to specify testfiles, and handle
exceptions. Apart from that, anything missing or could be explained better?

- Noel

On 25 April 2018 at 07:17, Noel O'Boyle <baoille...@gmail.com> wrote:

> On the topic of documentation, here's what I've got so far. Anything
> missing?
>
> On 17 April 2018 at 06:58, David van der Spoel <sp...@xray.bmc.uu.se>
> wrote:
>
>> Den 2018-04-17 kl. 07:51, skrev Noel O'Boyle:
>>
>>> To avoid digressing, absolutely we would like to do this and have the
>>> technical means to enforce...once we reduce the warnings. I did a certain
>>> amount already this year. Once a particular type of warning is eliminated
>>> we can add it as a requirement using gcc's treat warnings as errors. But
>>> we're not there yet. Like Geoff says, we encourage people to help.
>>>
>>> If there's some other way this can be enforced on a patch by patch basis
>>> (e.g. controlling for an increase in warnings), I'd be interested to hear.
>>> Maybe you can point me to the relevant person over at Gromacs.
>>>
>>> The GROMACS system uses gerrit https://www.gerritcodereview.com/ for
>> reviewing code and jenkins for building in the background
>> https://jenkins.io/index.html
>>
>> As far as I understand this is not entirely trivial to maintain, but once
>> it is set up it works nicely.
>>
>>
>> - Noel
>>>
>>>
>>> On Tue, 17 Apr 2018, 05:18 David van der Spoel, <sp...@xray.bmc.uu.se
>>> <mailto:sp...@xray.bmc.uu.se>> wrote:
>>>
>>> Den 2018-04-16 kl. 22:46, skrev Dominik 'Rathann' Mierzejewski:
>>>  > On Monday, 16 April 2018 at 20:20, David van der Spoel wrote:
>>>  >> Den 2018-04-16 kl. 17:36, skrev David Koes:
>>>  >>> I didn't chime in since I thought it was obviously a good idea.
>>>  >>> However, I strongly agree that the process of creating a test
>>> case needs
>>>  >>> to be as simple and documented as possible.  I had a test case
>>> with my
>>>  >>> last pull request, but it required a fair amount of poking
>>> around to
>>>  >>> figure out how to best implement it (and this experience
>>> prompted the
>>>  >>> GSoC project).
>>>  >>>
>>>  >>> Also, test cases may not make sense for some pull requests (e.g.
>>>  >>> documentation).
>>>  >>
>>>  >> Agree tests are a must.
>>>  >>
>>>  >> How about making warning-free code a must?
>>>  >
>>>  > Warning-free under which compiler (and version)? GCC adds new
>>> warnings
>>>  > in every release.
>>> Under all compilers. Obviously we can only fix the warnings we are
>>> getting.
>>>
>>> We have this policy in http://www.gromacs.org and it is enforced
>>> automatically by the robot that verifies patches. No patches that
>>> produce warnings on any platform (Linux, Mac, Windows) will be
>>> accepted.
>>>
>>>  >
>>>  > Regards,
>>>  > Dominik
>>>  >
>>>
>>>
>>> -- David van der Spoel, Ph.D., Professor of Biology
>>> Head of Department, Cell & Molecular Biology, Uppsala University.
>>> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
>>> http://www.icm.uu.se
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> OpenBabel-Devel mailing list
>>> OpenBabel-Devel@lists.sourceforge.net
>>> <mailto:OpenBabel-Devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>> <https://lists.sourceforge.net/lists/listinfo/openbabel-devel>
>>>
>>>
>>
>> --
>> David van der Spoel, Ph.D., Professor of Biology
>> Head of Department, Cell & Molecular Biology, Uppsala University.
>> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
>> http://www.icm.uu.se
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

On the topic of documentation, here's what I've got so far. Anything
missing?

On 17 April 2018 at 06:58, David van der Spoel <sp...@xray.bmc.uu.se> wrote:

> Den 2018-04-17 kl. 07:51, skrev Noel O'Boyle:
>
>> To avoid digressing, absolutely we would like to do this and have the
>> technical means to enforce...once we reduce the warnings. I did a certain
>> amount already this year. Once a particular type of warning is eliminated
>> we can add it as a requirement using gcc's treat warnings as errors. But
>> we're not there yet. Like Geoff says, we encourage people to help.
>>
>> If there's some other way this can be enforced on a patch by patch basis
>> (e.g. controlling for an increase in warnings), I'd be interested to hear.
>> Maybe you can point me to the relevant person over at Gromacs.
>>
>> The GROMACS system uses gerrit https://www.gerritcodereview.com/ for
> reviewing code and jenkins for building in the background
> https://jenkins.io/index.html
>
> As far as I understand this is not entirely trivial to maintain, but once
> it is set up it works nicely.
>
>
> - Noel
>>
>>
>> On Tue, 17 Apr 2018, 05:18 David van der Spoel, <sp...@xray.bmc.uu.se
>> <mailto:sp...@xray.bmc.uu.se>> wrote:
>>
>> Den 2018-04-16 kl. 22:46, skrev Dominik 'Rathann' Mierzejewski:
>>  > On Monday, 16 April 2018 at 20:20, David van der Spoel wrote:
>>  >> Den 2018-04-16 kl. 17:36, skrev David Koes:
>>  >>> I didn't chime in since I thought it was obviously a good idea.
>>  >>> However, I strongly agree that the process of creating a test
>> case needs
>>  >>> to be as simple and documented as possible.  I had a test case
>> with my
>>  >>> last pull request, but it required a fair amount of poking
>> around to
>>  >>> figure out how to best implement it (and this experience
>> prompted the
>>  >>> GSoC project).
>>  >>>
>>  >>> Also, test cases may not make sense for some pull requests (e.g.
>>  >>> documentation).
>>  >>
>>  >> Agree tests are a must.
>>  >>
>>  >> How about making warning-free code a must?
>>  >
>>  > Warning-free under which compiler (and version)? GCC adds new
>> warnings
>>  > in every release.
>> Under all compilers. Obviously we can only fix the warnings we are
>> getting.
>>
>> We have this policy in http://www.gromacs.org and it is enforced
>> automatically by the robot that verifies patches. No patches that
>> produce warnings on any platform (Linux, Mac, Windows) will be
>> accepted.
>>
>>  >
>>  > Regards,
>>  > Dominik
>>  >
>>
>>
>> -- David van der Spoel, Ph.D., Professor of Biology
>> Head of Department, Cell & Molecular Biology, Uppsala University.
>> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
>> http://www.icm.uu.se
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> <mailto:OpenBabel-Devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>> <https://lists.sourceforge.net/lists/listinfo/openbabel-devel>
>>
>>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> http://www.icm.uu.se
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

To avoid digressing, absolutely we would like to do this and have the
technical means to enforce...once we reduce the warnings. I did a certain
amount already this year. Once a particular type of warning is eliminated
we can add it as a requirement using gcc's treat warnings as errors. But
we're not there yet. Like Geoff says, we encourage people to help.

If there's some other way this can be enforced on a patch by patch basis
(e.g. controlling for an increase in warnings), I'd be interested to hear.
Maybe you can point me to the relevant person over at Gromacs.

- Noel

On Tue, 17 Apr 2018, 05:18 David van der Spoel, 
wrote:

> Den 2018-04-16 kl. 22:46, skrev Dominik 'Rathann' Mierzejewski:
> > On Monday, 16 April 2018 at 20:20, David van der Spoel wrote:
> >> Den 2018-04-16 kl. 17:36, skrev David Koes:
> >>> I didn't chime in since I thought it was obviously a good idea.
> >>> However, I strongly agree that the process of creating a test case
> needs
> >>> to be as simple and documented as possible.  I had a test case with my
> >>> last pull request, but it required a fair amount of poking around to
> >>> figure out how to best implement it (and this experience prompted the
> >>> GSoC project).
> >>>
> >>> Also, test cases may not make sense for some pull requests (e.g.
> >>> documentation).
> >>
> >> Agree tests are a must.
> >>
> >> How about making warning-free code a must?
> >
> > Warning-free under which compiler (and version)? GCC adds new warnings
> > in every release.
> Under all compilers. Obviously we can only fix the warnings we are getting.
>
> We have this policy in http://www.gromacs.org and it is enforced
> automatically by the robot that verifies patches. No patches that
> produce warnings on any platform (Linux, Mac, Windows) will be accepted.
>
> >
> > Regards,
> > Dominik
> >
>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
> http://www.icm.uu.se
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

I'm disappointed in the lack of support for this. David Koes - you
suggested a GSoc on this topic, for example. Anyway, for my part, I will
write up info on adding testcases, but also start to nudge PR submitters
towards including testcases.

Regards,
- Noel



On 3 April 2018 at 13:15, Noel O'Boyle <baoille...@gmail.com> wrote:

> Noted. We will do this. In fact, I commit to doing this whether or not
> this proposal goes ahead.
>
> - Noel
>
> On 3 April 2018 at 11:54, David Hall <li...@cowsandmilk.net> wrote:
>
>> I mostly agree, but I’ll mention the big hurdle I came across the first
>> time I wrote a test for openbabel.
>>
>> Many times, one comes across a bug when using the command line tools,
>> e.g. obabel , so debugging and testing goes through using that program.
>>
>> I think (correct if I’m wrong), the easiest way to go from an obabel
>> command line run to a test is through writing a test in python like those
>> that import functions from testbabel
>>
>> Having a document we can point to that walks them through that process,
>> and shows them that it is quite easy, might be helpful. I know my first few
>> times looking at the test directory, I said “well, I’m not using the python
>> bindings, so I’ll ignore those files and try to figure out the c++ files
>> and how they run tests”, when the reality is that the python files provide
>> the easy route to testing the command line programs.
>>
>> -David
>>
>>
>> > On Apr 3, 2018, at 4:42 AM, Noel O'Boyle <baoille...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > Very few PRs come with test cases. Basically, we just don't know if any
>> of them do what they say, and even if they do, they probably will bit rot
>> at a future date due to other PRs. The irony is that the person who wrote
>> the code clearly tested it (one would assume) - but just didn't check in
>> the test case. I would argue that the majority of developer time spent on
>> Open Babel is on fixing bugs (or bitrotted code) which would never have
>> existed in the first place if a test had been added.
>> >
>> > When I refactored the code to handle implict valence, I relied on the
>> small number of existing tests to help return the code back to its
>> preexisting state. Anything that wasn't tested may (still) not be working.
>> For example, recently David Koes found that my changes broke the PDBQT
>> format.
>> >
>> > In short, I propose that we require a testcase for every PR. There may
>> be special circumstances (huge test files, build system changes), but this
>> would be the general rule. As a lower bar, one could imagine requiring them
>> for every new feature implemented.
>> >
>> > Regards,
>> > - Noel
>> > 
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
>> _
>> > OpenBabel-Devel mailing list
>> > OpenBabel-Devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

Noted. We will do this. In fact, I commit to doing this whether or not this
proposal goes ahead.

- Noel

On 3 April 2018 at 11:54, David Hall <li...@cowsandmilk.net> wrote:

> I mostly agree, but I’ll mention the big hurdle I came across the first
> time I wrote a test for openbabel.
>
> Many times, one comes across a bug when using the command line tools, e.g.
> obabel , so debugging and testing goes through using that program.
>
> I think (correct if I’m wrong), the easiest way to go from an obabel
> command line run to a test is through writing a test in python like those
> that import functions from testbabel
>
> Having a document we can point to that walks them through that process,
> and shows them that it is quite easy, might be helpful. I know my first few
> times looking at the test directory, I said “well, I’m not using the python
> bindings, so I’ll ignore those files and try to figure out the c++ files
> and how they run tests”, when the reality is that the python files provide
> the easy route to testing the command line programs.
>
> -David
>
>
> > On Apr 3, 2018, at 4:42 AM, Noel O'Boyle <baoille...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Very few PRs come with test cases. Basically, we just don't know if any
> of them do what they say, and even if they do, they probably will bit rot
> at a future date due to other PRs. The irony is that the person who wrote
> the code clearly tested it (one would assume) - but just didn't check in
> the test case. I would argue that the majority of developer time spent on
> Open Babel is on fixing bugs (or bitrotted code) which would never have
> existed in the first place if a test had been added.
> >
> > When I refactored the code to handle implict valence, I relied on the
> small number of existing tests to help return the code back to its
> preexisting state. Anything that wasn't tested may (still) not be working.
> For example, recently David Koes found that my changes broke the PDBQT
> format.
> >
> > In short, I propose that we require a testcase for every PR. There may
> be special circumstances (huge test files, build system changes), but this
> would be the general rule. As a lower bar, one could imagine requiring them
> for every new feature implemented.
> >
> > Regards,
> > - Noel
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
> _
> > OpenBabel-Devel mailing list
> > OpenBabel-Devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Proposal to require test cases

[Noel O'Boyle]

Hi all,

Very few PRs come with test cases. Basically, we just don't know if any of
them do what they say, and even if they do, they probably will bit rot at a
future date due to other PRs. The irony is that the person who wrote the
code clearly tested it (one would assume) - but just didn't check in the
test case. I would argue that the majority of developer time spent on Open
Babel is on fixing bugs (or bitrotted code) which would never have existed
in the first place if a test had been added.

When I refactored the code to handle implict valence, I relied on the small
number of existing tests to help return the code back to its preexisting
state. Anything that wasn't tested may (still) not be working. For example,
recently David Koes found that my changes broke the PDBQT format.

In short, I propose that we require a testcase for every PR. There may be
special circumstances (huge test files, build system changes), but this
would be the general rule. As a lower bar, one could imagine requiring them
for every new feature implemented.

Regards,
- Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] compilation error of developing version

[Noel O'Boyle]

Should be fixed now.

On 17 March 2018 at 21:31, Mohammad Mehdi Ghahremanpour <
ghahramanpou...@gmail.com> wrote:

> Fellow developers,
>
> I just synced my fork with master and I got this compilation error:
>
>
> [ 72%] Built target pubchem
> *Scanning dependencies of target xmlformat*
> *openbabel/src/formats/moldenformat.cpp:144:30: **error: **use of
> undeclared identifier 'etab'*
>   atomicNumber = etab.GetAtomicNum(atomName.c_str());
>
>
> Any clue?
>
> Cheers,
>
> Mohammad
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Proposal: Store reactions as annotated molecules

[Noel O'Boyle]

My proposal is open for comments. See:
https://github.com/openbabel/enhancement-proposals/pull/8

Regards,
  Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] First pass at converting Open Babel wiki to Jekyll

[Noel O'Boyle]

There's bits and pieces on different pages that are worth keeping but I
don't know that the pages themselves should form part of a new website.In
other words, after removing clearly unneeded pages (e.g. the formats) I'd
put everything down into a legacy subdirectory and just create a simple
clear website with the essentials...whatever that is. :-) The eventual goal
would be to either move or delete all the information from legacy.

I'm happy to go through the pages and do some of this, once everything is
in place.

On 9 February 2018 at 17:31, Geoffrey Hutchison 
wrote:

> I'm currently in the process of converting the MediaWiki site to a Jekyll
> site (e.g., like https://avogadro.cc/)
>
> - Pages can still be edited through GitHub
> - We can easily merge in the rewritten documentation https://open-babel.
> readthedocs.io/en/latest/
>
> What I'd like to ask is "what parts of the old site are worth keeping?"
> (that aren't in the readthedocs version)
> - Descriptions of force fields
> - Old release notes
>
> Right now, I have 278 Markdown files, most of which are old file format
> docs..
> http://github.com/openbabel/openbabel.github.io/pages/
>
> -Geoff
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release 3.0

[Noel O'Boyle]

Hi David,

I'd love to have the time to do everything perfectly. Yes, we should have a
deprecation phase, with compiler warnings, and messages generated by the
bindings. But eventually, the changes will still break the build. What we
do need are migration docs at the least.

Regards,
- Noel

On 12 January 2018 at 14:43, Koes, David <dk...@pitt.edu> wrote:

> Hi Noel,
>
> I’m mostly just grumpy because these changes broke my build. Have you
> considered going through a deprecated phase?
>
> From your email, I thought you were saying you added an IsElement method
> to OBAtom, but this doesn’t seem to be the case. Something like:
>  OBAtom.IsElement(OBElement::Hydrogen)
> is quite readable and it’s much more general than a specific helper
> function.  There’s also no need worry about subtle bugs incurred from
> incorrectly accounting for operator precedence (e.g., the == in
> GetAtomicNum() == 1).
>
> You could even shorten the name to “Is”:
> atom->Is(OBElement::Hydrogen)
>
> David Koes
>
> Assistant Professor
> Computational & Systems Biology
> University of Pittsburgh
>
>
> On Jan 12, 2018, at 9:01 AM, Noel O'Boyle <baoille...@gmail.com> wrote:
>
> Hi David,
>
> We don't break backwards compatability lightly. The last time was 12 years
> ago. In that time, there has been some accumulation of cruft, and in
> addition there are some necessary changes in order to fix underlying
> problems.
>
> Regarding the specific functions you mention, the IsElement() functions
> are, as you say, convenience functions, some of which date back to the
> original Stahl/Walters Babel. While GetAtomicNumber() == 1 is less readable
> and error prone as you say, I have added the elements as enums,
> OBElement::Hydrogen, to mitigate this. Furthermore, while the IsElement()
> methods only covered a small number of elements, the ones where people are
> most likely to know the atomic number (where's IsFluorine() for instance),
> the OBElement namespace covers them all.
>
> So why have I removed them? They are convenience functions trivially
> implementable in terms of the remaining API. There is nothing to prevent a
> user implementing the function themselves as a macro or whatever. From the
> port of Open Babel to remove these function, I can give examples of where
> the use of these functions results in inefficient code. Obviously there are
> two function lookups instead of one. But also, I have seen constructions
> like "if atom->IsHydrogen then this; else if atom->IsCarbon then this; and
> so on. In other words, instead of getting the atomic number once and
> switching on it, the maximum possible amount of work is done.
>
> Regarding IsSingle(), the situation is more clear cut. This is a function
> which appears to be (and is documented to be) synonymous with
> GetBondOrder() == 1. Aha, but it is not, and only by looking at the source
> code would you have realised the difference. It was a surprise to me, and I
> think it is used synonymous with GetBondOrder==1 throughout the
> codebase...but there's no way to tell what the caller intended. All we can
> do is prevent nasty surprises for users in the future. This change was made
> in combination with an overhaul of the treatment of kekulization and
> aromaticity last year.
>
> Regards,
> - Noel
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Release 3.0

[Noel O'Boyle]

Hi David,

We don't break backwards compatability lightly. The last time was 12 years
ago. In that time, there has been some accumulation of cruft, and in
addition there are some necessary changes in order to fix underlying
problems.

Regarding the specific functions you mention, the IsElement() functions
are, as you say, convenience functions, some of which date back to the
original Stahl/Walters Babel. While GetAtomicNumber() == 1 is less readable
and error prone as you say, I have added the elements as enums,
OBElement::Hydrogen, to mitigate this. Furthermore, while the IsElement()
methods only covered a small number of elements, the ones where people are
most likely to know the atomic number (where's IsFluorine() for instance),
the OBElement namespace covers them all.

So why have I removed them? They are convenience functions trivially
implementable in terms of the remaining API. There is nothing to prevent a
user implementing the function themselves as a macro or whatever. From the
port of Open Babel to remove these function, I can give examples of where
the use of these functions results in inefficient code. Obviously there are
two function lookups instead of one. But also, I have seen constructions
like "if atom->IsHydrogen then this; else if atom->IsCarbon then this; and
so on. In other words, instead of getting the atomic number once and
switching on it, the maximum possible amount of work is done.

Regarding IsSingle(), the situation is more clear cut. This is a function
which appears to be (and is documented to be) synonymous with
GetBondOrder() == 1. Aha, but it is not, and only by looking at the source
code would you have realised the difference. It was a surprise to me, and I
think it is used synonymous with GetBondOrder==1 throughout the
codebase...but there's no way to tell what the caller intended. All we can
do is prevent nasty surprises for users in the future. This change was made
in combination with an overhaul of the treatment of kekulization and
aromaticity last year.

Regards,
- Noel

On 11 January 2018 at 21:26, David Koes  wrote:

> I'd like to advocate for _not_ removing simple convenience functions like
> OBAtom->IsHydrogen, OBBond->IsSingle.  I don't see any benefit: it breaks
> backwards compatibility, using GetAtomicNumber() == 1 is less readable and
> more error prone, and GetBondOrder() == 1 doesn't have the same semantics
> as IsSingle did.
>
> My two cents.
>
> David Koes
>
> Assistant Professor
> Computational & Systems Biology
> University of Pittsburgh
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Performance tests

[Noel O'Boyle]

Hi Geoff,

I've been looking into whether Travis provides some means to indicate
performance changes, but it seems not, and I kind of understand why:
https://github.com/travis-ci/travis-ci/issues/352 (2011)
https://github.com/travis-ci/travis-ci/issues/3313 (2015)

Given that that's the case, is it still worth doing? What did you have in
mind?

Regards,
- Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Migrating from MediaWiki

[Noel O'Boyle]

Sounds good.

On 24 October 2017 at 21:05, Geoffrey Hutchison 
wrote:

> Hi everyone,
>
> I’d like to modernize the Open Babel webpages, including migrating away
> from MediaWiki to Markdown / Jekyll.
>
> The idea behind the MediaWiki site was to enable anyone to edit.
> Unfortunately, unlike Wikipedia, we don’t have the same level of anti-spam
> resilience. So we had to move to a “human-approved”  account system, which
> sorta defeats the purpose.
>
> I migrated the Avogadro website last year (https://avogadro.cc/) which
> now lives as a set of Markdown files on GitHub. People can click a link
> from the website and propose an edit - but with GitHub providing the
> authentication.
>
> One nice bonus is that I’d be able to integrate the documentation at
> ReadTheDocs directly:
> http://open-babel.readthedocs.io/en/latest/
>
> Before I do this for Open Babel, I wanted to get some opinions. Pro? Con?
> Ambivalent?
>
> -Geoff
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Version number on master

[Noel O'Boyle]

Ok - I'll make it so, if no-one else gets there first...

On 9 October 2017 at 14:23, Geoffrey Hutchison 
wrote:

> > Is it okay if I increment the version number on master? That is, to
> 2.4.2 (or something else if that's the usual procedure, e.g. 2.4.2dev).
>
> It’s definitely time to increment the version number, but we’d want 2.4.90
> or something to indicate that it has dev versions for 2.5.
>
> -Geoff
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Version number on master

[Noel O'Boyle]

Hey Geoff,

Is it okay if I increment the version number on master? That is, to 2.4.2
(or something else if that's the usual procedure, e.g. 2.4.2dev).

I've just gotten snap builds working a bit better now, and I'd like to make
dev versions available. This will be cleared marked as 2.4.2dev or
something, and the user will need to install by explicitly specifiying the
"edge channel", but without incrementing the version it will be confusing
to the user whether they are running the dev version or not.

Regards,
- Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Support for OBReaction in Python

[Noel O'Boyle]

Hi Geoff,

I've been looking into enabling support for OBReaction from Python, and
started with excavating what was previously tried.

Apparently, I added support back in 2013 via
https://github.com/openbabel/openbabel/pull/21. The catch with Swig is not
only are all OBMols turned into shared_ptrs, but everything in the
inheritance hierarchy too.

Reinis Danne found that this caused a pretty severe regression (mol +=
molb) and reverted the Python bindings changes in
https://github.com/openbabel/openbabel/pull/41.

I'm less optimistic now that there is a solution to this that involves
keeping the shared_ptrs, but am open to any ideas.

Regards,
Noel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Append molecular formula and molecular weight to SMILES format list

[Noel O'Boyle]

(This question is probably better suited to openbabel-discuss rather than
devel)

Just type "MW formula" into the box "Append properties or descriptors to
title". A list of available properties is in the menu under Plugins,
Descriptors.

On 16 August 2017 at 07:23, RicardoMBorges via OpenBabel-Devel <
openbabel-devel@lists.sourceforge.net> wrote:

> Dear all,
> I'm looking for a way to convert a series of .mol/.cdxml files into SMILES
> to add as a column in a .csv file (I can do it with openbabel GUI easy) but
> it would very helpful if I could also append molecular formula and
> molecular
> weight to SMILES format list aside from the filename tile
> Is it possible ?
>
> I only use the GUI...
>
> Thank you
>
>
>
> --
> View this message in context: http://forums.openbabel.org/
> Append-molecular-formula-and-molecular-weight-to-SMILES-
> format-list-tp4660194.html
> Sent from the openbabel-devel mailing list archive at Nabble.com.
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Pybel versus PyBEL

[Noel O'Boyle]

FYI, I filed an issue with PyBEL on the name conflict:

https://github.com/pybel/pybel/issues/217

Resolved as "won't fix" (my words).

Regards,
- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] pull request for an old patch

[Noel O'Boyle]

I think his edits were on master, so...after resetting they might have
disappeared. Still should be upstream though.

On 7 July 2017 at 15:11, Mohammad Mehdi Ghahremanpour
 wrote:
>
> On Jul 7, 2017, at 4:00 PM, Geoffrey Hutchison 
> wrote:
>
> Before doing that, my branch was ahead by 6 commits and was behind by
> several commits, while after rebasing it is written that my branch is ahead
> by 6 commits.
>
> How can I fix the rebasing if it was incorrect.
>
>
> Yeah, the problem as Noel indicated is that to do the review now, we have to
> sift through dozens of completely unrelated changes. I can't tell at all
> what are your changes for this particular pull request. It's a mess now.
>
> So the best solution is to create a new branch for a new request with just
> your commits.
>
> # Create a new branch:
> git checkout master
> git reset -- hard upstream/master # make sure your "master" only has the
> same as upstream
> git checkout -b my-new-patch
>
> # now "cherry-pick" the commits from your previous branch
> git cherry-pick # git commit ids.. maybe  9fdfc11 for example??
>
>
> Thank you for your solution. I did it but I am not sure if it worked
> properly.
> These are the messages I obtained:
>
> → git checkout master
> Already on 'master'
> Your branch is up-to-date with 'origin/master’.
>
> → git reset -- hard upstream/master
>
> → git checkout -b obthermo-update-patch
> Switched to a new branch 'obthermo-update-patco'
>
> → git cherry-pick 9fdfc1120fff9fd3009df4cfe8d789c92a49c1e1
> On branch obthermo-update-patch
> You are currently cherry-picking commit 9fdfc11.
>
> nothing to commit, working directory clean
> The previous cherry-pick is now empty, possibly due to conflict resolution.
> If you wish to commit it anyway, use:
>
> git commit --allow-empty
>
> Otherwise, please use 'git reset'
>
> Excuse my confusion! Should I commit it even though it is empty?
>
> Best,
> Mohammad
>
>
>
> # Then push the new branch as a pull request
>
> Hope that helps,
> -Geoff
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] pull request for an old patch

[Noel O'Boyle]

When something goes wrong with Git, it can be difficult to fix
especially given that you have been working on the master rather than
a branch. What you describe here is not a rebase, but even so, it
doesn't explain why so many files are included.

What I would do to fix this is delete my Github repo (but not my local
repo obviously - or else all is lost), fork it again, check it out
locally as a different new repo, create a branch for this fix, reapply
my changes manually by looking at the diffs in my original local repo,
push the branch to a branch on Github, and submit a new pull request.

Unless Geoff or someone else has a better suggestion...

- Noel

On 7 July 2017 at 14:42, Mohammad Mehdi Ghahremanpour
<ghahramanpou...@gmail.com> wrote:
> Hi Noel,
>
> Thanks for your reply.
>
> To rebase, I ran these commands
>
> git remote add upstream  https://github.com/openbabel/openbabel.git
> git fetch upstream
> git pull upstream master
> git push
>
> Before doing that, my branch was ahead by 6 commits and was behind by
> several commits, while after rebasing it is written that my branch is ahead
> by 6 commits.
>
> How can I fix the rebasing if it was incorrect.
>
> Thanks,
> Mohammad
>
> On Jul 7, 2017, at 3:26 PM, Noel O'Boyle <baoille...@gmail.com> wrote:
>
> I beg your pardon, here is the link:
> https://github.com/openbabel/openbabel/pull/337
>
> On 7 July 2017 at 14:25, Noel O'Boyle <baoille...@gmail.com> wrote:
>
> Hi Mohammad,
>
> Here is your pull request:
> https://github.com/openbabel/openbabel/pull/337/files/9fdfc1120fff9fd3009df4cfe8d789c92a49c1e1..beba494f1c977dca1af1279eab267d65c0f3261e
>
> I think that you have not rebased correctly. The pull request contains
> a huge number of commits that are unrelated to the change you are
> describing.
>
> Regards,
> - Noel
>
> On 7 July 2017 at 14:05, Mohammad Mehdi Ghahremanpour
> <ghahramanpou...@gmail.com> wrote:
>
> Hello developers,
>
> I requested pull for a patch updating obthermo on August 29, 2016 and fixed
> the problems of the patch on September 1, 2016. However, the patch has not
> been merged, yet. I have rebased the master branch in my fork and pushed
> again to request a new pull. Apparently, the new request has not been added
> to the list of Pull requests.
>
> This is the patch
> https://github.com/openbabel/openbabel/compare/master...mmghahremanpour:master
>
> How I can solve this problem?
>
> Thank you,
> Mohammad
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] pull request for an old patch

[Noel O'Boyle]

I beg your pardon, here is the link:
https://github.com/openbabel/openbabel/pull/337

On 7 July 2017 at 14:25, Noel O'Boyle <baoille...@gmail.com> wrote:
> Hi Mohammad,
>
> Here is your pull request:
> https://github.com/openbabel/openbabel/pull/337/files/9fdfc1120fff9fd3009df4cfe8d789c92a49c1e1..beba494f1c977dca1af1279eab267d65c0f3261e
>
> I think that you have not rebased correctly. The pull request contains
> a huge number of commits that are unrelated to the change you are
> describing.
>
> Regards,
> - Noel
>
> On 7 July 2017 at 14:05, Mohammad Mehdi Ghahremanpour
> <ghahramanpou...@gmail.com> wrote:
>> Hello developers,
>>
>> I requested pull for a patch updating obthermo on August 29, 2016 and fixed
>> the problems of the patch on September 1, 2016. However, the patch has not
>> been merged, yet. I have rebased the master branch in my fork and pushed
>> again to request a new pull. Apparently, the new request has not been added
>> to the list of Pull requests.
>>
>> This is the patch
>> https://github.com/openbabel/openbabel/compare/master...mmghahremanpour:master
>>
>> How I can solve this problem?
>>
>> Thank you,
>> Mohammad
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] pull request for an old patch

[Noel O'Boyle]

Hi Mohammad,

Here is your pull request:
https://github.com/openbabel/openbabel/pull/337/files/9fdfc1120fff9fd3009df4cfe8d789c92a49c1e1..beba494f1c977dca1af1279eab267d65c0f3261e

I think that you have not rebased correctly. The pull request contains
a huge number of commits that are unrelated to the change you are
describing.

Regards,
- Noel

On 7 July 2017 at 14:05, Mohammad Mehdi Ghahremanpour
 wrote:
> Hello developers,
>
> I requested pull for a patch updating obthermo on August 29, 2016 and fixed
> the problems of the patch on September 1, 2016. However, the patch has not
> been merged, yet. I have rebased the master branch in my fork and pushed
> again to request a new pull. Apparently, the new request has not been added
> to the list of Pull requests.
>
> This is the patch
> https://github.com/openbabel/openbabel/compare/master...mmghahremanpour:master
>
> How I can solve this problem?
>
> Thank you,
> Mohammad
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Isotope table

[Noel O'Boyle]

Hi Geoff,

I've just converted the isotope table in isotope.txt to a switch
statement in the code (elements.cpp in
https://github.com/baoilleach/openbabel/commit/91a320713f498e78db1b3e4579a1a87478f0c55a).
I have some more work to do with adding comments and so forth, but
what I'm wondering is, there's also a file isotope-small.txt. Am I
right in saying that this is legacy and I can ignore (and delete) it?

- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] JSON parsing of elements

[Noel O'Boyle]

Hi Matt,

I'm in the middle of
https://github.com/openbabel/enhancement-proposals/pull/4 and have
come to the JSON formats.

When parsing the PubChem JSON you try first whether it's an integer
and then later if it's a string. I think it's always an integer and
plan to remove the string code - is this okay? I assume that this is a
copy+paste of logic from the ChemDoodle JSON parsing where
(presumably) this can occur.

- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Explicit "implicit hydrogen" count and kekulisation now merged

[Noel O'Boyle]

Hi there,

At the start of the year (or was it last year?), I said to Geoff that
I felt that the single major problem with OB was its handling of
implicit hydrogens. And he called my bluff. :-)

Well, "the fix" has now been merged. Everything should be faster but
also more correct. As this is a major change, I encourage you to put
the library through its paces, and if you find any problems, please
file them and I'll sort them out. Radical support is still in the
process of being revived so you might experience some weirdness there
still. Feel free to report bugs if unsure.

There is no longer a "floating valence". Any OBAtom must have its
implicit hydrogen count set, or else it defaults to zero. A function
is provided to set the value based on typical valence (but you should
never need to use this as a user). Previously, you could create a bond
between any two atoms and the number of implicit hydrogens would
'adjust' automatically. Now you will need to decrement the implicit
hydrogen count yourself (there should be a shortcut function to do
this, but I can't remember if I've added this already).

There is no downside to this approach really - it's how almost all
other cheminformatics toolkits work since the dawn of time (though
OPSIN also uses this approach but apparently this fits with how IUPAC
names work). The floating valence was prone to getting the hydrogen
count wrong on occassion and made it difficult to, well, control the
hydrogen count without resort to a whole lot of atom flags.

The rewrite of kekulisation is more straightforward, and should be
transparent to the user, except that things that can't be kekulised
won't be kekulised.

Two new options have been added to SMILES:
1. -aa keep aromaticity as read (i.e. don't reperceive) - potential
speed boost for databases
e.g. obabel -:cc -aa -osmi # gives 'cc' (don't do this at home)
2. -xk write Kekule smiles (note: not canonical unless I do more work)
   e.g. obabel -:c1c1 -osmi -xk # gives C1C=CC=CC=1

For more info, please see the pull request,
https://github.com/openbabel/openbabel/pull/1576.

Regards,
- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Appveyor tests

[Noel O'Boyle]

I deliberately supply the InChI .lib and set the appropriate build
flags in order to speed up the build. Also to avoid build warnings
that are outside our control.

- Noel

On 12 June 2017 at 13:57, Maciek Wójcikowski <mac...@wojcikowski.pl> wrote:
> Hi,
>
> I wanted to follow up on the windows builds. My builds still have some
> issues, but the ones you had trouble with pass (at least with my PR with
> isnan fix). So I could say that they are artefact of your build setup on
> Appveyor an the code itself is fine. Note that Conda uses older MSVC
> specific to Python version in use.
> https://ci.appveyor.com/project/mwojcikowski/conda-openbabel/build/job/qh9ni508gq8754u2
>
> The issue with mine is InChI and few python ones, but I still have no clue
> why. I've seen you're supply external InChI .lib and link against them. I
> wander why the internal InChI is not recognized and built?
>
> 
> Pozdrawiam,  |  Best regards,
> Maciek Wójcikowski
> mac...@wojcikowski.pl
>
> 2017-06-09 15:24 GMT+02:00 Maciek Wójcikowski <mac...@wojcikowski.pl>:
>>
>> Apparently my last name killed conda build...
>> https://ci.appveyor.com/project/mwojcikowski/conda-openbabel/build/1.0.23/job/hvv95j1fagio4ike
>>
>> 
>> Pozdrawiam,  |  Best regards,
>> Maciek Wójcikowski
>> mac...@wojcikowski.pl
>>
>> 2017-06-09 15:19 GMT+02:00 Maciek Wójcikowski <mac...@wojcikowski.pl>:
>>>
>>> I'm on it as we speak.
>>>
>>> 
>>> Pozdrawiam,  |  Best regards,
>>> Maciek Wójcikowski
>>> mac...@wojcikowski.pl
>>>
>>> 2017-06-09 15:09 GMT+02:00 Noel O'Boyle <baoille...@gmail.com>:
>>>>
>>>> Thanks for the super quick response. I do appreciate it.
>>>>
>>>> There is a std::isnan via _isnan build problem which will require a
>>>> #define for particular MSVC versions, but that's nothing to do with my
>>>> pull request.
>>>>
>>>> Ok - I'm going to do ahead and silence the tests
>>>>
>>>> - Noel
>>>>
>>>> On 9 June 2017 at 13:56, Maciek Wójcikowski <mac...@wojcikowski.pl>
>>>> wrote:
>>>> > I'm getting different errors on current master, see
>>>> >
>>>> > https://ci.appveyor.com/project/mwojcikowski/conda-openbabel/build/1.0.19
>>>> > I need to fix conda recipe for git master first, but I think we should
>>>> > merge
>>>> > it as is and figure out what is the issue with tests later on.
>>>> >
>>>> > 
>>>> > Pozdrawiam,  |  Best regards,
>>>> > Maciek Wójcikowski
>>>> > mac...@wojcikowski.pl
>>>> >
>>>> > 2017-06-09 14:23 GMT+02:00 Noel O'Boyle <baoille...@gmail.com>:
>>>> >>
>>>> >> I'm keen to get my code merged, so I'm going to press you on this.
>>>> >> I've spent several months getting these tests to 100% passing. I'm
>>>> >> happy to send a screenshot showing this on my Windows machine.
>>>> >>
>>>> >> - Noel
>>>> >>
>>>> >> On 6 June 2017 at 20:52, Noel O'Boyle <baoille...@gmail.com> wrote:
>>>> >> > The link is on the PR:
>>>> >> > https://ci.appveyor.com/project/baoilleach/openbabel/build/1.0.501
>>>> >> >
>>>> >> > Ok - I'll wait until you confirm.
>>>> >> >
>>>> >> > - Noel
>>>> >> >
>>>> >> > On 5 June 2017 at 19:18, Maciek Wójcikowski <mac...@wojcikowski.pl>
>>>> >> > wrote:
>>>> >> >> We need to verify that it doesn't mess up the conda packages for
>>>> >> >> windows.
>>>> >> >> I'll have some time by the end of the week.
>>>> >> >>
>>>> >> >> PS.
>>>> >> >> https://ci.appveyor.com/project/baoilleach/openbabel/build/1.0.481
>>>> >> >> this
>>>> >> >> build says 100% tests passed. Am I looking at the wrong one?
>>>> >> >>
>>>> >> >> 
>>>> >> >> Pozdrawiam,  |  Best regards,
>>>> >> >> Maciek Wójcikowski
>>>> >> >> mac...@wojcikowski.pl
>>>> >> >>
>>>> >> >> 2017-06-05 19:17 GMT+0

Re: [OpenBabel-Devel] Appveyor tests

[Noel O'Boyle]

Thanks for the super quick response. I do appreciate it.

There is a std::isnan via _isnan build problem which will require a
#define for particular MSVC versions, but that's nothing to do with my
pull request.

Ok - I'm going to do ahead and silence the tests

- Noel

On 9 June 2017 at 13:56, Maciek Wójcikowski <mac...@wojcikowski.pl> wrote:
> I'm getting different errors on current master, see
> https://ci.appveyor.com/project/mwojcikowski/conda-openbabel/build/1.0.19
> I need to fix conda recipe for git master first, but I think we should merge
> it as is and figure out what is the issue with tests later on.
>
> 
> Pozdrawiam,  |  Best regards,
> Maciek Wójcikowski
> mac...@wojcikowski.pl
>
> 2017-06-09 14:23 GMT+02:00 Noel O'Boyle <baoille...@gmail.com>:
>>
>> I'm keen to get my code merged, so I'm going to press you on this.
>> I've spent several months getting these tests to 100% passing. I'm
>> happy to send a screenshot showing this on my Windows machine.
>>
>> - Noel
>>
>> On 6 June 2017 at 20:52, Noel O'Boyle <baoille...@gmail.com> wrote:
>> > The link is on the PR:
>> > https://ci.appveyor.com/project/baoilleach/openbabel/build/1.0.501
>> >
>> > Ok - I'll wait until you confirm.
>> >
>> > - Noel
>> >
>> > On 5 June 2017 at 19:18, Maciek Wójcikowski <mac...@wojcikowski.pl>
>> > wrote:
>> >> We need to verify that it doesn't mess up the conda packages for
>> >> windows.
>> >> I'll have some time by the end of the week.
>> >>
>> >> PS.
>> >> https://ci.appveyor.com/project/baoilleach/openbabel/build/1.0.481 this
>> >> build says 100% tests passed. Am I looking at the wrong one?
>> >>
>> >> 
>> >> Pozdrawiam,  |  Best regards,
>> >> Maciek Wójcikowski
>> >> mac...@wojcikowski.pl
>> >>
>> >> 2017-06-05 19:17 GMT+02:00 Noel O'Boyle <baoille...@gmail.com>:
>> >>>
>> >>> Hey Geoff,
>> >>>
>> >>> I'm going to turn off tests for the Appveyor build due to the problems
>> >>> with PR#1572. I don't think they are real - do you remember a similiar
>> >>> issue with a PR of David Koes, where I had exactly the same problem
>> >>> (except here it's multiple tests)? Something's funny with the VMs that
>> >>> Appveyor use. If it's real, obviously we'll have to sort it out, but
>> >>> the tests pass for me. The main reason for the windows build is simply
>> >>> for compilation, so while not ideal, I don't think it's a major issue.
>> >>>
>> >>> - Noel
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>> ___
>> >>> OpenBabel-Devel mailing list
>> >>> OpenBabel-Devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>> >>
>> >>
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Appveyor tests

[Noel O'Boyle]

I'm keen to get my code merged, so I'm going to press you on this.
I've spent several months getting these tests to 100% passing. I'm
happy to send a screenshot showing this on my Windows machine.

- Noel

On 6 June 2017 at 20:52, Noel O'Boyle <baoille...@gmail.com> wrote:
> The link is on the PR:
> https://ci.appveyor.com/project/baoilleach/openbabel/build/1.0.501
>
> Ok - I'll wait until you confirm.
>
> - Noel
>
> On 5 June 2017 at 19:18, Maciek Wójcikowski <mac...@wojcikowski.pl> wrote:
>> We need to verify that it doesn't mess up the conda packages for windows.
>> I'll have some time by the end of the week.
>>
>> PS.
>> https://ci.appveyor.com/project/baoilleach/openbabel/build/1.0.481 this
>> build says 100% tests passed. Am I looking at the wrong one?
>>
>> 
>> Pozdrawiam,  |  Best regards,
>> Maciek Wójcikowski
>> mac...@wojcikowski.pl
>>
>> 2017-06-05 19:17 GMT+02:00 Noel O'Boyle <baoille...@gmail.com>:
>>>
>>> Hey Geoff,
>>>
>>> I'm going to turn off tests for the Appveyor build due to the problems
>>> with PR#1572. I don't think they are real - do you remember a similiar
>>> issue with a PR of David Koes, where I had exactly the same problem
>>> (except here it's multiple tests)? Something's funny with the VMs that
>>> Appveyor use. If it's real, obviously we'll have to sort it out, but
>>> the tests pass for me. The main reason for the windows build is simply
>>> for compilation, so while not ideal, I don't think it's a major issue.
>>>
>>> - Noel
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> OpenBabel-Devel mailing list
>>> OpenBabel-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Appveyor tests

[Noel O'Boyle]

Hey Geoff,

I'm going to turn off tests for the Appveyor build due to the problems
with PR#1572. I don't think they are real - do you remember a similiar
issue with a PR of David Koes, where I had exactly the same problem
(except here it's multiple tests)? Something's funny with the VMs that
Appveyor use. If it's real, obviously we'll have to sort it out, but
the tests pass for me. The main reason for the windows build is simply
for compilation, so while not ideal, I don't think it's a major issue.

- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] FYI, Implicit hydrogens and kekulization branch

[Noel O'Boyle]

I'm feeling good. All tests now pass. A few bugs fixed here and there
in passing, and a lot of insight into parts of the code I've never
previously touched.

Now I need to tidy things up a bit, rebase and send a pull request.
Oh, and someone's going to have to review it. Good luck with that,
Geoff :-)

- Noel

On 14 April 2017 at 11:22, Noel O'Boyle <baoille...@gmail.com> wrote:
> If you're interested in what I hope will be the future of OB, you can
> try out my work on changing the handling of implicit hydrogens and
> implementing a new kekulization algorithm:
> https://github.com/baoilleach/openbabel/tree/workingimph
>
> This is partly to let people know that there's work in progress and
> partly to get some early feedback or field questions. Essentially, the
> main difference is that atoms record how many implicit hydrogens are
> attached. Previously, OB performed heroic efforts to work this out
> based on other information but at the expense of speed and the
> occassional mistake.
>
> It's by no means finished (several test failures), but it's all there
> in broad strokes. It should be quite a bit faster than the current
> release. I've added an option when reading SMILES to keep the
> aromaticity present in the SMILES (a performance improvement when
> reading aromatic SMILES written by OB, e.g. in a database context),
> and the option to write kekule SMILES.
>
> Regards,
> - Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] GSoC project introduction - C.C. web repository

[Noel O'Boyle]

Hi Nitish,

Welcome and best of luck. Hope you enjoy your project, and I look
forward to seeing your progress.

- Noel O'Boyle

On 8 May 2017 at 14:06, Nitish Garg <nitish.garg.6...@gmail.com> wrote:
> Hi everyone,
>
> I am working on the project "Computational Chemistry Web repository" during
> GSoC 2017.
> This project will require using cclib, 3Dmol.js, OpenBabel (and probably
> RDKit in extension of this project) and thus, it suits to introduce this
> project to the various mailing lists.
>
> This project is completely new and I would love to receive ideas from the
> community on additional functionalities that can be added to this project.
> Also, the official name of this project is yet to be fixed. I had suggested
> 'CCviewer'. Let us discuss an appropriate name for the project.
>
> Project abstract:
> cclib is used to parse calculation results from various chemistry software
> log files. This project will be a flask-based framework making use of cclib
> to parse a collection of such log files, store the parsed data in a database
> and enable searching & filtering of these data records via a REST API. The
> web front-end will be based on this API. Also, a chemistry software log file
> can be uploaded on the webpage which will be parsed with cclib to show the
> results.
> Thus, this project will provide a web GUI for cclib, add searching
> capability and also make use of 3Dmol.js to visualize the molecule in
> browser (when file is uploaded as well as in search results).
>
> I had started with the simple functionality of showing parsed results from
> uploaded file. The current code can be seen at :
> https://github.com/nitish6174/cclib-web.
> I hope to migrate the code to a new repository under OpenChemistry's github.
>
> Thanks,
> Nitish Garg
> B.Tech undergraduate, IIT Guwahati
> GitHub : https://github.com/nitish6174
> Website : http://nitish6174.com/
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] BEP: Proposal for removal of Kekule and Aromatic Bond Orders

[Noel O'Boyle]

Hi there,

Geoff has established a "Babel Enhancement Proposal" (or BEP) system
for proposing and discussing changes to the API. This is to be done on
Github via a new repo.

To check out my first proposal, see:
 
https://github.com/baoilleach/enhancement-proposals/blob/master/remove_kekule_and_aromatic_bond_orders/remove_kekule_and_aromatic_bond_orders.md

To discuss, see the associated pull request:
https://github.com/openbabel/enhancement-proposals/pull/2

Regards,
- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Moving trackers from SF to GitHub

[Noel O'Boyle]

A week or two ago, Geoff migrated bugs (/etc?) from SF over to Github.

After some fiddling, just now I figured out how to put the SF bug/etc
trackers into read-only mode. If you go there yourself as a developer,
you may still see the "Create" button but regular users won't.

If you are on this list and do not already have a Github account,
consider creating one and clicking "Watch" over at our Github project
to help us out with responding to bug reports, pull requests, etc.
That's where 50% of the discussions are happening now.

Regards,
- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] API/ABI changes review for OpenBabel

[Noel O'Boyle]

Hi Andrey,

This is very useful although we find that ABI compliance checker has
false positives. What would be super useful is Github integration on
pull requests. Even if this was not something you yourself had the
resources to support, if you had a recipe for projects to set up
Github hooks ourselves that would be cool.

Regards,
- Noel

On 20 March 2017 at 06:57, Andrey Ponomarenko
 wrote:
> Hello,
>
> Here is the review of API/ABI changes for OpenBabel since 2.2.0 version: 
> https://abi-laboratory.pro/tracker/timeline/openbabel/
>
> The report is updated 3 times a week. Hope it will be helpful for users and 
> maintainers of the library.
>
> Created with the help of open-source abi-tracker tool: 
> https://github.com/lvc/abi-tracker
>
> Thank you.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Mailing list change proposal

[Noel O'Boyle]

May I suggest that we change openbabel-dev to only allow posting by
members? That is, that posts by non-members are rejected (with a
message) without review. This would reduce the admin burden on spam
filtering. There is a list of existing non-members with posting rights
on the mailman interface, and they could be contacted off-list to let
them know of any changes.

I won't go so far as to suggest the same for openbabel-discuss, but
it's worth considering whether it would be a net benefit to the
project to have this, with the idea that it builds community. (I heard
this argument a few years back from the lead dev for Gromacs.)

- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Convenience functions

[Noel O'Boyle]

The previous discussion was about having such a function in the public API.
But anyway, let's say you do use smarts, you can still combine it with a
switch statement on element and maybe on something else so that you don't
end up testing the oxygen patterns against a nitrogen (this will already
make it three times faster or so). Regarding your specific examples I think
you just need to rewrite so that the first atom is the query atom. Also
avoid using an explicit hydrogen - this won't work like you expect.

I'm hoping to do away with dependencies on text files (as this complicates
having an all in one binary) at some point so putting your patterns in a
const char array would be welcome. Doing the perception once and then
storing it may indeed be a good idea but the user can do this without us
getting involved. Maintaining perceived data is a source of errors and
inefficiencies in the current codebase.

Noel

On Thursday, 2 March 2017, Stefano Forli <fo...@scripps.edu> wrote:

> Noel,
>
> I'm not sure how to describe all the cases with a switch statement.
> The original idea of using SMARTS came from your suggestion:
>
> The thing is, if I was matching a functional group, I would just use a
>> SMARTS pattern. This is a general solution for 99% of cases, rather
>> than having a function for each one. We have a set of SMARTS patterns
>> for functional groups in the .txt file for FP3. The added benefit of a
>> SMARTS pattern is that you have the match of each atom to each virtual
>> atom of the pattern. For a function of OBAtom, it's just boolean true
>> or false.
>>
>
> and you convinced me that's an excellent idea.
>
> Hydrogen bond types can be: 0 (none), 1 (acceptor), 2 (donor),
> acceptor/donor (3), and there are several conditions that need to be
> checked.
> For that, I'm creating SMARTS patterns which would reproduce the behavior
> of the current IsHBondAcceptor() which are stored in text datafile. As an
> example, this is a subset of the conditions in which oxygen is not
> considered an hbonding oxygen:
>
>  # nitro-oxygen
>  [#8]~N~[#8]   0 0
>
>  # aromatic-bound oxygen
>  [a]-[#8]-[a]1 0
>
>  # ester sp3 oxygen
>  [*]-[#8]-[#6]=[#8] 1 0
>
>  # sulfone
>  [#6][#16;X4](=[#8])(=[#8])[#6] 2 0
>
>  # hydroxyl
>  [#8]-[#1]  0 3
>
> The line format is (pattern, patternIdx, hbType). Basically, the typer
> checks the condition OBAtom.GetIdx() == pattern[patternIdx], then return
> type "hbType".
> Between N, O, S and F, there are about 20 or so patterns to be tested, so
> I though doing the perception once and storing it would have been a good
> idea. On the other hand, I don't think performance is an issue for this
> kind of functions.
>
> I have no idea how to implement this with a switch statement without
> having to do the bond/atom walking manually, as I did in the functions I
> contributed already.
>
> Hope this helps,
>
> S
>
>
>
>
> On 03/02/2017 01:28 PM, Noel O'Boyle wrote:
>
>> The presence of a class or not is an "implementation detail", as they
>> say. That is, the user doesn't need to know anything about that.
>> However, as I am currently replacing the use of SMARTS patterns for
>> atom typers with switch statements, I'd recommend you to avoid using
>> SMARTS for this in the first place and thus avoid any need for a class
>> or a file to read things from. Maybe you should describe the exact
>> problem you are solving with some examples and I can explain better.
>>
>> - Noel
>>
>> On 2 March 2017 at 19:51, Stefano Forli <fo...@scripps.edu> wrote:
>>
>>> Noel,
>>> thanks for the clarification, the only reason why I was looking at the
>>> lazy
>>> mechanism was because of previous code.
>>>
>>> I'm OK with the simple function, although I think there's still a need
>>> for a
>>> dedicated class behind which gets called to parse the different SMARTS
>>> patterns from a data file and match them with the requested atom.
>>>
>>> S
>>>
>>>
>>>
>>>
>>> On 03/02/2017 02:22 AM, Noel O'Boyle wrote:
>>>
>>>>
>>>> Hi Stefano,
>>>>
>>>> Sounds good. But the guidelines are not unfortunately the existing
>>>> guide. I'm currently in the process of rewriting/removing as much of
>>>> the croft as possible and the Lazy Evaluation mechanism is in my
>>>> sights. It's a legacy from the original codebase. It'll be difficult
>>>> to change this now, but at least we can avoid adding anything. I won't
>>>> go too much into why

Re: [OpenBabel-Devel] Change to SMILES writer for hypervalent atoms

[Noel O'Boyle]

The discussion over at opensmiles was that both forms are reasonable and
Geoff prefers the current behavior, so I'll stick to that.

On Thursday, 2 March 2017, Andrew Dalke  wrote:

> On Mar 2, 2017, at 21:31, Andrew Dalke  > wrote:
> >> In practice, one chemist might represent nitromethane as C[N+](=O)[O-]
> with a nitrogen of valence 3 in a charge-separated structure while another
> might represent it as CN(=O)=O with a neutral 5-valent nitrogen. Which
> SMILES is correct? Both are.
>
> I'm sorry. I sent that without fully double-checking/proof-reading. That
> is not a counter-example.
>
> I'll see if I can find an actual counter-example.
>
> I still think it should be changed.
>
>
> Andrew
> da...@dalkescientific.com 
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Convenience functions

[Noel O'Boyle]

The presence of a class or not is an "implementation detail", as they
say. That is, the user doesn't need to know anything about that.
However, as I am currently replacing the use of SMARTS patterns for
atom typers with switch statements, I'd recommend you to avoid using
SMARTS for this in the first place and thus avoid any need for a class
or a file to read things from. Maybe you should describe the exact
problem you are solving with some examples and I can explain better.

- Noel

On 2 March 2017 at 19:51, Stefano Forli <fo...@scripps.edu> wrote:
> Noel,
> thanks for the clarification, the only reason why I was looking at the lazy
> mechanism was because of previous code.
>
> I'm OK with the simple function, although I think there's still a need for a
> dedicated class behind which gets called to parse the different SMARTS
> patterns from a data file and match them with the requested atom.
>
> S
>
>
>
>
> On 03/02/2017 02:22 AM, Noel O'Boyle wrote:
>>
>> Hi Stefano,
>>
>> Sounds good. But the guidelines are not unfortunately the existing
>> guide. I'm currently in the process of rewriting/removing as much of
>> the croft as possible and the Lazy Evaluation mechanism is in my
>> sights. It's a legacy from the original codebase. It'll be difficult
>> to change this now, but at least we can avoid adding anything. I won't
>> go too much into why this is, but suffice to say that OB developers
>> spend some time working around the lazy evaluation or if they don't
>> they triggeri it multiple times unneccessarily.
>>
>> In short, see if you can write a function that just takes an atom (or
>> pair of atoms, or whatever) and returns an answer., e.g.
>> OBAtomGetHBondType(OBAtom*). The simpler solution really is the best
>> one here.
>>
>> - Noel
>>
>> On 1 March 2017 at 23:17, Stefano Forli <fo...@scripps.edu> wrote:
>>>
>>> Noel,
>>> quite the contrary, I'm far from being pissed at you, by all means.
>>> I like your suggestion, but I don't know if I can do it right away, there
>>> are still a few things about the facade programming paradigm that escape
>>> my
>>> hobbist programming training.
>>>
>>> Following up on the discussion about the hydrogen bond, I had a quick
>>> chat
>>> with one of my students which is starting to write code based on
>>> OpenBabel.
>>> We took a shot at designing an OBHBondTyper class which should behave
>>> similarly to OBAromaticTyper, and my idea was to store the information in
>>> a
>>> vector.
>>>
>>> If I'm not mistaken, though, the aromatic typer works in a lazy way that
>>> looks similar to what you're describing for the OBResidueFacade, storing
>>> the
>>> information in a flag instead of a vector, is that correct? Or is the
>>> flag
>>> is just in vector? I tried looking for the definition of HasFlag(), but I
>>> couldn't find it.
>>>
>>> Either way, I was thinking to start by writing this HB class (which I
>>> probably understand better), try implementing the ob-standard lazy
>>> evaluation mechanism, and integrate it the [Begin|End]Modify() process.
>>>
>>> We can do a git pull and then fix and adapt it according to the feedback
>>> other developers suggestions.
>>>
>>> This would be a great chance for us to understand how to contribute code
>>> that would integrate better and match the guidelines you guys follow.
>>>
>>> Thanks (for the patience),
>>>
>>> S
>>>
>>>
>>>
>>>
>>>
>>> On 02/26/2017 02:05 AM, Noel O'Boyle wrote:
>>>>
>>>>
>>>> Thanks Stefano for not getting (too!) pissed off with me. :-) We still
>>>> don't have the clear API guidelines you asked for last time, but I
>>>> think that these discussions are clarifying things for me at least,
>>>> and we could probably start writing something up.
>>>>
>>>> I was thinking that your idea is similar to the rationale behind
>>>> OBStereoFacade. Well, simply put, we could have an OBResidueFacade
>>>> class which you initialise with a molecule and behind the scenes it
>>>> then stores the Atom->PDBAtomId correspondance in a map or vector by
>>>> iterating over the residues. Then you would have the same method you
>>>> described, but it wouldn't do any iteration, but just look up the Id
>>>> in the std::map or vector. So, it's a convenience class, separate from
>>>

Re: [OpenBabel-Devel] Change to SMILES writer for hypervalent atoms

[Noel O'Boyle]

To avoid multiple threads, let's move this over to the opensmiles list.

On 2 March 2017 at 20:31, Andrew Dalke  wrote:
> On Mar 2, 2017, at 20:34, Craig James  wrote:
>> Well, "FIF" violates the OpenSMILES spec in section 3.1.5, which states that 
>> the "organic subset" are only allowed outside of brackets if they're in 
>> their normal lowest-valence state. Actually, now that I read it, it's not 
>> well written and has room for (mis)interpretation. The phrase that I think 
>> applies in OpenSMILES is:
>
> My understanding of Daylight SMILES is that when the explicit valence based 
> on the bonds is higher than the maximum natural valence then the deduced 
> hydrogen count is 0.
>
> For example, quoting 
> http://www.daylight.com/meetings/summerschool98/course/dave/smiles-intro.html 
> :
>
>> In practice, one chemist might represent nitromethane as C[N+](=O)[O-] with 
>> a nitrogen of valence 3 in a charge-separated structure while another might 
>> represent it as CN(=O)=O with a neutral 5-valent nitrogen. Which SMILES is 
>> correct? Both are.
>
>
>
>
> On Mar 2, 2017, at 20:34, Craig James  wrote:
>> If you can say, "It's obvious ...", and this is a feature everyone would 
>> like, then the OpenSMILES spec could be changed.
>
> I think it should be changed.
>
> Andrew
> da...@dalkescientific.com
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Change to SMILES writer for hypervalent atoms

[Noel O'Boyle]

Hi Craig,

>From what you say, it sounds like this is a better discussion for the
OpenSMILES list. My intention is to match existing usage and what I
believe to be Daylight usage. Let's have this discussion over there,
and can clarify the spec either way depending on the outcome.

- Noel



On 2 March 2017 at 19:34, Craig James <cja...@emolecules.com> wrote:
> Hi Noel,
>
> On Thu, Mar 2, 2017 at 10:11 AM, Noel O'Boyle <baoille...@gmail.com> wrote:
>>
>> In the course of sorting out the handling of implicit Hs, I've found
>> that the current SMILES writer writes hypervalent atoms from the
>> organic subset in square brackets. E.g. Texas carbons:
>>
>> >obabel -:C(C)(C)(C)(C)C -osmi
>> [C](C)(C)(C)(C)C
>>
>> or "FIF" as "F[I]F".
>>
>> This is unusual behaviour compared to other toolkits and I think lack
>> of brackets are preferred where possible, so I've changed this (on my
>> branch). If this is an issue for anyone, now's the time to duke it
>> out.
>
>
> Well, "FIF" violates the OpenSMILES spec in section 3.1.5, which states that
> the "organic subset" are only allowed outside of brackets if they're in
> their normal lowest-valence state. Actually, now that I read it, it's not
> well written and has room for (mis)interpretation. The phrase that I think
> applies in OpenSMILES is:
>
> An atom is specified [without brackets] has the following properties:
>
> "implicit hydrogens" are added such that valence of the atom is in the
> lowest normal state for that element
>
> You might argue from this that since you don't have to add any hydrogens,
> it's clear what it means. But someone else might say, "you have to add
> charge to balance it."
>
> Daylight's page is more clear. It says:
>
> ... the "organic subset" B, C, N, O, P, S, F, Cl, Br, and I may be written
> without brackets if the number of attached hydrogens conforms to the lowest
> normal valence consistent with explicit bonds.
>
>
> If you can say, "It's obvious ...", and this is a feature everyone would
> like, then the OpenSMILES spec could be changed.
>
> Craig
>
>>
>>
>> - Noel
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Change to SMILES writer for hypervalent atoms

[Noel O'Boyle]

Hi there,

In the course of sorting out the handling of implicit Hs, I've found
that the current SMILES writer writes hypervalent atoms from the
organic subset in square brackets. E.g. Texas carbons:

>obabel -:C(C)(C)(C)(C)C -osmi
[C](C)(C)(C)(C)C

or "FIF" as "F[I]F".

This is unusual behaviour compared to other toolkits and I think lack
of brackets are preferred where possible, so I've changed this (on my
branch). If this is an issue for anyone, now's the time to duke it
out.

- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [OpenBabel-Devel] Convenience functions

[Noel O'Boyle]

Typo: "But the guidelines are not unfortunately the existing code. "

On 2 March 2017 at 10:22, Noel O'Boyle <baoille...@gmail.com> wrote:
> Hi Stefano,
>
> Sounds good. But the guidelines are not unfortunately the existing
> guide. I'm currently in the process of rewriting/removing as much of
> the croft as possible and the Lazy Evaluation mechanism is in my
> sights. It's a legacy from the original codebase. It'll be difficult
> to change this now, but at least we can avoid adding anything. I won't
> go too much into why this is, but suffice to say that OB developers
> spend some time working around the lazy evaluation or if they don't
> they triggeri it multiple times unneccessarily.
>
> In short, see if you can write a function that just takes an atom (or
> pair of atoms, or whatever) and returns an answer., e.g.
> OBAtomGetHBondType(OBAtom*). The simpler solution really is the best
> one here.
>
> - Noel
>
> On 1 March 2017 at 23:17, Stefano Forli <fo...@scripps.edu> wrote:
>> Noel,
>> quite the contrary, I'm far from being pissed at you, by all means.
>> I like your suggestion, but I don't know if I can do it right away, there
>> are still a few things about the facade programming paradigm that escape my
>> hobbist programming training.
>>
>> Following up on the discussion about the hydrogen bond, I had a quick chat
>> with one of my students which is starting to write code based on OpenBabel.
>> We took a shot at designing an OBHBondTyper class which should behave
>> similarly to OBAromaticTyper, and my idea was to store the information in a
>> vector.
>>
>> If I'm not mistaken, though, the aromatic typer works in a lazy way that
>> looks similar to what you're describing for the OBResidueFacade, storing the
>> information in a flag instead of a vector, is that correct? Or is the flag
>> is just in vector? I tried looking for the definition of HasFlag(), but I
>> couldn't find it.
>>
>> Either way, I was thinking to start by writing this HB class (which I
>> probably understand better), try implementing the ob-standard lazy
>> evaluation mechanism, and integrate it the [Begin|End]Modify() process.
>>
>> We can do a git pull and then fix and adapt it according to the feedback
>> other developers suggestions.
>>
>> This would be a great chance for us to understand how to contribute code
>> that would integrate better and match the guidelines you guys follow.
>>
>> Thanks (for the patience),
>>
>> S
>>
>>
>>
>>
>>
>> On 02/26/2017 02:05 AM, Noel O'Boyle wrote:
>>>
>>> Thanks Stefano for not getting (too!) pissed off with me. :-) We still
>>> don't have the clear API guidelines you asked for last time, but I
>>> think that these discussions are clarifying things for me at least,
>>> and we could probably start writing something up.
>>>
>>> I was thinking that your idea is similar to the rationale behind
>>> OBStereoFacade. Well, simply put, we could have an OBResidueFacade
>>> class which you initialise with a molecule and behind the scenes it
>>> then stores the Atom->PDBAtomId correspondance in a map or vector by
>>> iterating over the residues. Then you would have the same method you
>>> described, but it wouldn't do any iteration, but just look up the Id
>>> in the std::map or vector. So, it's a convenience class, separate from
>>> the core API, and it's efficient. If no-one disagrees and this makes
>>> sense to you, do you want to have a go at writing it?
>>>
>>> - Noel
>>>
>>> On 25 February 2017 at 23:03, Geoffrey Hutchison
>>> <geoff.hutchi...@gmail.com> wrote:
>>>>>
>>>>> About the PDB atom name, unfortunately I don't fully understand the
>>>>> performance issue implied in my suggestion, but from an interface point of
>>>>> view, it seems more intuitive to access an atom property from OBAtom 
>>>>> instead
>>>>> of going back to the OBResidue (and pass the OBAtom).
>>>>
>>>>
>>>> The OBAtom should already have a pointer to the OBResidue. If it can be
>>>> done with generic data in the OBAtom, that's fine, but I don't think I want
>>>> to add data to each OBAtom. If I translate a nanotube or nanoparticle (or
>>>> any other non-biomolecule) I'd have to store in memory a bunch of residue
>>>> pointers that would never get used.
>>>>
>>>>> In this case, the best approach I can think of is to write a
>>>>&

Re: [OpenBabel-Devel] Convenience functions

[Noel O'Boyle]

Hi Stefano,

Sounds good. But the guidelines are not unfortunately the existing
guide. I'm currently in the process of rewriting/removing as much of
the croft as possible and the Lazy Evaluation mechanism is in my
sights. It's a legacy from the original codebase. It'll be difficult
to change this now, but at least we can avoid adding anything. I won't
go too much into why this is, but suffice to say that OB developers
spend some time working around the lazy evaluation or if they don't
they triggeri it multiple times unneccessarily.

In short, see if you can write a function that just takes an atom (or
pair of atoms, or whatever) and returns an answer., e.g.
OBAtomGetHBondType(OBAtom*). The simpler solution really is the best
one here.

- Noel

On 1 March 2017 at 23:17, Stefano Forli <fo...@scripps.edu> wrote:
> Noel,
> quite the contrary, I'm far from being pissed at you, by all means.
> I like your suggestion, but I don't know if I can do it right away, there
> are still a few things about the facade programming paradigm that escape my
> hobbist programming training.
>
> Following up on the discussion about the hydrogen bond, I had a quick chat
> with one of my students which is starting to write code based on OpenBabel.
> We took a shot at designing an OBHBondTyper class which should behave
> similarly to OBAromaticTyper, and my idea was to store the information in a
> vector.
>
> If I'm not mistaken, though, the aromatic typer works in a lazy way that
> looks similar to what you're describing for the OBResidueFacade, storing the
> information in a flag instead of a vector, is that correct? Or is the flag
> is just in vector? I tried looking for the definition of HasFlag(), but I
> couldn't find it.
>
> Either way, I was thinking to start by writing this HB class (which I
> probably understand better), try implementing the ob-standard lazy
> evaluation mechanism, and integrate it the [Begin|End]Modify() process.
>
> We can do a git pull and then fix and adapt it according to the feedback
> other developers suggestions.
>
> This would be a great chance for us to understand how to contribute code
> that would integrate better and match the guidelines you guys follow.
>
> Thanks (for the patience),
>
> S
>
>
>
>
>
> On 02/26/2017 02:05 AM, Noel O'Boyle wrote:
>>
>> Thanks Stefano for not getting (too!) pissed off with me. :-) We still
>> don't have the clear API guidelines you asked for last time, but I
>> think that these discussions are clarifying things for me at least,
>> and we could probably start writing something up.
>>
>> I was thinking that your idea is similar to the rationale behind
>> OBStereoFacade. Well, simply put, we could have an OBResidueFacade
>> class which you initialise with a molecule and behind the scenes it
>> then stores the Atom->PDBAtomId correspondance in a map or vector by
>> iterating over the residues. Then you would have the same method you
>> described, but it wouldn't do any iteration, but just look up the Id
>> in the std::map or vector. So, it's a convenience class, separate from
>> the core API, and it's efficient. If no-one disagrees and this makes
>> sense to you, do you want to have a go at writing it?
>>
>> - Noel
>>
>> On 25 February 2017 at 23:03, Geoffrey Hutchison
>> <geoff.hutchi...@gmail.com> wrote:
>>>>
>>>> About the PDB atom name, unfortunately I don't fully understand the
>>>> performance issue implied in my suggestion, but from an interface point of
>>>> view, it seems more intuitive to access an atom property from OBAtom 
>>>> instead
>>>> of going back to the OBResidue (and pass the OBAtom).
>>>
>>>
>>> The OBAtom should already have a pointer to the OBResidue. If it can be
>>> done with generic data in the OBAtom, that's fine, but I don't think I want
>>> to add data to each OBAtom. If I translate a nanotube or nanoparticle (or
>>> any other non-biomolecule) I'd have to store in memory a bunch of residue
>>> pointers that would never get used.
>>>
>>>> In this case, the best approach I can think of is to write a
>>>> OBHBondTyper class to perceive the hbond character (similarly to what
>>>> OBAromaticTyper does), then each atom should have a simple IsHBond() method
>>>> that would return 0, 1 (donor), 2 (acceptor), 3(donor/acceptor), 4(...?).
>>>
>>>
>>> Yes, this is the way to go to add "convenience functions." Noel's
>>> suggestion is to keep the core API restrained, but that doesn't mean there
>>> can't be convenience classes or static methods. I think HBond

Re: [OpenBabel-Devel] Proposal to overhaul/replace OBElementTable

[Noel O'Boyle]

These days I've got a Python script that generates switch statements.

On 25 Feb 2017 11:06 p.m., "Geoffrey Hutchison" 
wrote:

> > 2. The GetAtomicNum() will be a compiled prefix tree using switch
> > statements. Right now, if you ask what is the atomic number of Fermium
> > (element 100), it will do 100 string comparisons.
>
> Fair enough - does it make sense to hand-write the switch statements,
> though?
>
> > 4. We can add an enum for atomic symbols, in anticipation (perhaps) of
> > removing OBAtom::IsCarbon() and friends in place of
> > OBAtom::GetAtomicNum() == OBElem:Carbon
>
> This sounds like a nice idea.
>
> -Geoff
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

[OpenBabel-Devel] Convenience functions

[Noel O'Boyle]

Hi there,

As some of you know, I would like to remove all convenience functions
from classes in Open Babel. I would like to explain why.

It's hard to exactly define a convenience function, but it's an
addition to the API that is implemented entirely using existing API
calls  and that makes it easier to do certain things. There may be a
place for these in the documentation (e.g. usage examples as OEChem
does) or in a convenience.cpp, but I argue that they should never be
part of any Open Babel classes, and in particular, should never be
used internally by the API.

One reason is that it clogs up the core API, which affects both
compilation speed and reading the API looking for functions. It's also
API duplication - there should be one way to do something. Also, there
are a infinite number of convenience functions and once you let one in
(e.g. OBAtom::IsCarbon()), you must then let in 100+ other ones.

A more subtle reason is that they obscure the correct usage of the
underlying core API, as users cannot know they are convenience
functions. Sounds a bit vague? Here are two examples.

Let's take the duplicated std::string versus const char* functions I
mentioned in an earlier email. The std::string version just calls the
const char* function. Some of these convenience functions do an
unnecessary string copy. On top of this, a user of the toolkit, having
a char* to hand but needing to choose between the methods, may
construct a std::string (another copy) to call the std::string method
because stack overflow tells us to always use C++ STL objects. So,
adding the convenience functions had the unintended consequence of two
string copies.

Another example is the convenience function that Stefano has proposed
that loops over the Residues to return the PDBAtomId for an OBAtom. I
don't disagree this is useful, but it's still a convenience function.
Now imagine a user who writes a loop over all the atoms in a molecule
calling this function. They end up using an N squared function, which
is going to be a fairly significant slowdown for PDB files. But there
was no way for them to know that this was not the correct method to
call.

The current API has many such convenience functions. Let's make a
bonfire (e.g. called convenience.cpp) and burn them all.

- Noel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel