All, I apologize for packing two questions in one chain, but now that it's done, I don't want to break chain.
As an organic chemist, I got dragged into this coordination compound issue kicking and screaming - "So it goes." Here's a blog that uses ferrocene in PubChem as an example of the problem: http://depth-first.com/articles/2006/12/12/the-problem-with-ferrocene/ I'd still value any opinions on how this should be handled in the Jmol sandbox. The thing that suddenly makes establishing some standard an issue is the recent inclusion of SMILES and model editing into the power tool kit of Jmol. Otis Otis Rothenberger chemagic.com On 11/11/2010 8:37 PM, Otis Rothenberger wrote: > All- > > I'm looking for some advice from inorganic chemists (or others) on the > subject of appropriate molfiles for coordination compounds. To put the > question in perspective, we are assembling a database of organic > compounds found in standard organic text. This list will, of course, > include some coordination compounds. The database will include, _A_ > SMILES that Jmol creates for the model, _THE_ unique SMILES that NIH > Resolver creates, a common name, the IUPAC name, and a hook to the > molfile. > > It is the SMILES & molfile that present a problem for coordination > compounds. What is the standard (if any exists) for creating > coordinate bonds in a molfile? It appears that a common approach is to > not show bonds at all (PubChem and Emolecules seem to do this for > example), with the resulting SMILES being a multi-structure SMILES. > For our purpose, a single bound geometry retaining entity is > preferred. We can create the unconnected model in Spartan, and then > append/edit the molfile connection table to show coordinate bonds. Is > there a preference or some standard for the molfiles of these > compounds? Single, partial, unidentified are among the molefile options. > > Bob is the master of Jmol SMILES, so I'll direct the second question > to him. > > The SMILES on these compounds present another problem in Jmol. By way > of example, if we construct an unconnected ferrocene in SPARTAN and > then edit the molfile connection table so that the cyclopentadienyl > anion carbons are assigned "aromatic" and the coordinate bonds to iron > are assigned as type 8 ("any", evidently interpreted by Jmol as > partial ), then we get the following SMILES from Jmol: > > [...@h]12[fe]3456789%10[c@H]%11[C@@H]%10[C@@H]9[C@@h]...@h]%117.[c@H]16[C@@H]5[C@@h]...@h]23 > > > > The NIH Resolver reads this and returns evidence that it understands > the bond connections - correctly connected 2D molfile and correctly > connected GIF image. This appears to be a correct SMILES for the > ferrocene that we constructed. It appears that the SMILES is very > confused about the geometry of the cylopentadienyl anion hydrogens, > but the connections are correct. > > Unfortunately, Jmol does not seem to recognize what it created. With > the same model in the Jmol window, the following : > > var x = > "[...@h]12[fe]3456789%10[c@H]%11[C@@H]%10[C@@H]9[C@@h]...@h]%117.[c@H]16[C@@H]5[C@@h]...@h]23"; > > var y = {*}.find("SMILES",x);echo @y > > does not produce a match. Resolver will also produce a unique SMILES > from Jmol's SMILES: > > [...@h]12[c@@H]3[C@@H]4[C@@h]...@h]1[fe]23456789[c@H]%10[C@@H]6[C@@H]7[C@@H]8[C@@H]9%10 > > > > The following SMILES Find (Resolver in Jmol) is a perfect match: > > var x = > "[...@h]12[c@@H]3[C@@H]4[C@@h]...@h]1[fe]23456789[c@H]%10[C@@H]6[C@@H]7[C@@H]8[C@@H]9%10"; > > var y = {*}.find("SMILES",x);echo @y > > Help! > > Otis > ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
