Now added in r4898. Option "S" for read or write gives former 2.3.1 behaviour.
"obabel -:C/C=C/Cl -omol" still includes a warning message as follows: *** Open Babel Warning in OpenBabel::MDLFormat::WriteMolecule No 2D or 3D coordinates exist. Stereochemical information will be stored using an Open Babel extension. To generate 2D or 3D coordinates instead use --gen2D or --gen3D. - Noel On 21 June 2012 16:13, Craig James <cja...@emolecules.com> wrote: > Hi Noel, > > I'm back from my vacation and caught up with the seemingly inevitable > backlog of stuff that build up... now back to reality! > > On Sun, May 20, 2012 at 10:15 AM, Noel O'Boyle <baoille...@gmail.com> wrote: >> >> On 16 May 2012 16:28, Craig James <cja...@emolecules.com> wrote: >>> >>> On Mon, May 14, 2012 at 3:46 AM, Noel O'Boyle <baoille...@gmail.com> >>> wrote: >>>> >>>> See also this thread: >>>> http://www.mail-archive.com/blueobelisk-discuss@lists.sourceforge.net/msg00665.html >>>> >>>> ....where Greg Landrum dissuades me from including stereo in 0D Mol >>>> file. >>> >>> >>> Here's how that conversation ended. Greg wrote: >>> >>> >> So...should we retain them or not? I think what I'll do is add an >>> >> option to allow users to retain them exactly. However, the default >>> >> will be that the wedges/hashes in the output will be solely dependent >>> >> on the perceived stereochemistry. *Sigh* This applies to all 2D output >>> >> formats. >>> > >>> > Having the option to retain them exactly sounds sensible, but that >>> > means retaining all of the user-provided markings, right? This almost >>> > sounds to me like it's a read setting, not a write one. But then I'm >>> > not familiar with the internal flow for processing mols in OB. >>> >>> It seemed to me like the opposite (maybe Greg is following this now?). >>> At the end of this discussion, I was left with the understanding that >>> OpenBabel *would* keep the 0D stereo information, or at least optionally be >>> able to keep it. >>> >>> And in that same thread, Peter beat me in making all my key arguments. >>> In particular: >>> >>> >>> http://www.mail-archive.com/blueobelisk-discuss@lists.sourceforge.net/msg00666.html >>> >>> ... in which Peter argues that editors tend to draw zig-zag bonds by >>> default, so you can't rely on 2D coordinates to deduce whether an author >>> really meant cis or trans. And more to the point, Peter closes by saying: >>> >>> >> For 0D coordinates, there are no guidelines. I propose to store >>> >> cis/trans stereo using the bond stereo (you know, UP [or DOWN] at both >>> >> ends of a double bond means cis), and chirality using the atom parity. >>> >> The MDL spec states that atom parity should be ignored when read, >>> > >>> > I know this is the spec and I don't want to get into more arguments >>> > about >>> > whether it should be changed. At this stage I think it is useful if >>> > programs >>> > have the capability to read and interpret this field. >>> >>> Exactly. >>> >>> To reiterate my earlier argument, I just can't see any reason not to >>> include cis/trans and chiral information in 0D SD Files. It's genuinely >>> useful, and it doesn't hurt anything. The fact that it stretches the CTFile >>> spec strikes me as uninteresting. Apps are free to ignore it. >>> >>> Craig >> >> >> Ok - I'll add it back. > > > Can you tell me where we stand on this? > > Thanks! > Craig > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
