On Thu, Feb 14, 2013 at 5:38 PM, Chris Morley <c.mor...@gaseq.co.uk> wrote: > On 14/02/2013 16:48, David Lonie wrote: >> There seems to a bug when adding hydrogens to a molecule with only a >> single atom: >> >> $ cat /tmp/t.cml >> <?xml version="1.0"?> >> <molecule xmlns="http://www.xml-cml.org/schema";> >> <atomArray> >> <atom id="a1" elementType="C" x3="0.386206" y3="1.895920" >> z3="-0.000004"/> >> </atomArray> >> </molecule> >> >> $ obabel -icml /tmp/t.cml -ocml -h >> <?xml version="1.0"?> >> <molecule spinMultiplicity="5" xmlns="http://www.xml-cml.org/schema";> >> <atomArray> >> <atom id="a1" elementType="C" spinMultiplicity="5" x3="0.386206" >> y3="1.895920" z3="-0.000004"/> >> </atomArray> >> </molecule> >> 1 molecule converted >> >> It works fine if there are 2 carbons. This is with today's trunk. >> >> Should I file a bug, or is this expected behavior for some reason? > > AddHydrogens(false, false) (called by the -h option) makes implicit > hydrogen into explicit hydrogen. It usually does not change the molecule > by adding hydrogen to radicals, charged species or multiple bonds. > So > obabel -:[C] -:[C][C] -ocml -h > <snip> > > adds no hydrogen (explicit or implicit). I think this the correct behaviour. > > However there is a special behaviour for multi-atom molecules with no > bonds (see line 2395 in mol.cpp): > > obabel -:[C].[C] -ocml -h > <snip> > > It is this behaviour which is suspect in the essential non-editing > obabel interface because the molecule is altered. Ii is there so that a > compchem file with no bonds could be converted into a cml file with just > the atoms (sometimes good enough): > > obabel -:[O].[C].[O] -ocml
That is great to know, and wasn't clear to me when looking at the format documentation. > > With normal use of obabel I expect this non-standard behaviour would > rarely occur. But you are doing tricky things (like editing molecules) > to subvert the licence. It is not really "subverting the license", we are using obabel as a service in a separate process which is perfectly legitimate. It may be that we are using obabel to do things it wasn't necessarily designed to do, and if that is so knowing whether these are bugs or intended behaviors is very helpful. > > Have you considered writing an op and building it by itself in a > DLL(*.obf) or shared library? It could be then be added to an existing > OpenBabel installation (without any rebuilding) to give custom > capability by running obabel. > If we did that we may as well write a custom executable (which I have experimented with). We would like to be able to discover a standard, installed obabel at runtime and simply use it (or let our user point us at a better one). If we start compiling against the library then we gain a lot more control (and can still execute it in a separate process). There are several issues besides licensing motivating using the Open Babel API in a separate process, such as issues when using the API in a multithreaded application due to widespread use of global variables. I think obabel is able to provide 90% of what I was hoping for, and if we discover bugs we have time to fix them too. Largely we wanted basic file conversion, and geometry optimization in an isolated process allowing us to execute parallel processes when desired. Thanks for the feedback on obabel, and why it behaves the way it does in this case. Marcus ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
