On 2 March 2010 09:40, Peter Murray-Rust <pm...@cam.ac.uk> wrote: > Thanks, > This is a useful initiative > > On Tue, Mar 2, 2010 at 9:14 AM, Noel O'Boyle <baoille...@gmail.com> wrote: >> >> (Reposted from my blog following Greg's suggestion ) >> >> Hello all, >> >> Right now, I'm adding stereo (i.e. double bond stereochemistry, and >> chirality) to the MDL Mol format in OpenBabel. There are three places >> where stereochemical information can be stored in these files: the >> coordinates, the atom parity (in the atom block), the bond stereo (in >> the bond block). >> >> My current understanding is that where 3D coordinates are present, >> there's no need to store stereochemical information in either the atom >> parity or the bond block. I think I'll probably set the atom parity >> anyway (since I've already written the code, and it helps when you >> look at the file to be able to easily identify the chiral centers). >> > > The main problem is lack of information as to whether the geometry (2D or > 3D) is definitive or arbitrary. It is impossible to construct a 3D model of > (say) alanine without a perceived stereochemistry at the Carbon. Similarly > most modern 2D graphic programs will draw a double bond as cis or trans (not > normally linear although this was common in typesetting). If the (arbitrary) > geometry is then transmitted without details of authoring, then the reader > may assume a definitive stereochemistry. Put another way, there is no way of > indicating by coordinates alone that stereochemistry is unknown. I thinks > it's very important not to use the geometry as definitive unless it is clear > that the author specified it (which normally only comes from crystal > structures or computational chemistry).
Sure, but I think this is outside the scope here. > P. > >> >> For 2D coordinates, there's no need to store the bond stereochemistry >> (as this can be worked out from the coordinates), but chirality needs >> to be stored explicitly. The normal way to store this is not using >> atom parity (but I'll set this anyway for the same reasons as above), >> but by setting one of the bonds on the tetrahedral center to up or >> down. >> >> 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. I think that I may move this to an option. So, if you don't explicitly ask for it, you will just get what the spec says - i.e. no stereochemistry will be stored if there are no coordinates. >> >> but >> the alternative is to just forget the stereochemistry, or else to >> store both cis/trans stereo *and* chirality in the bond block, which >> may just about be possible but is likely to be a real mess. >> > Is it ambiguous or merely complicated? If the latter then we should use it > to remove ambiguity. As it is (for 2D), it's already ambiguous. The interpretation of a hash or wedge bond between two stereocentres is ambiguous (as in one toolkit may interpret as describing the stereo only at the start, while another might interpret it as describing the stereo at the beginning and end). In the case of 0D, if you cram all of the stereochemical information into the bond block it will only get worse; you will have situations like a stereochemical center attached to a double bond. Can the same single bond be used to indicate both cis/trans across the double bond, and the chirality of the center? All of these problems can be avoided using conventions, but the spec doesn't go that far. > > > > > -- > Peter Murray-Rust > Reader in Molecular Informatics > Unilever Centre, Dep. Of Chemistry > University of Cambridge > CB2 1EW, UK > +44-1223-763069 > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Blueobelisk-discuss mailing list Blueobelisk-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
