On 30 August 2011 16:21, Vincent Favre-Nicolin <vinc...@users.sourceforge.net> wrote: > Le 30/08/2011 16:35, Noel O'Boyle a écrit : >> For some time I have been using hashizume.cif (in >> scripts/python/examples) to test the Python bindings. Some time ago, >> the test started to fail due to the text below which now appears which >> hashizume.cif is read: >> >> user@ubuntu904desktop:~/Tools/openbabel/nightly/ob-build/test$ >> ../../ob-build/bin/obabel >> ../../openbabel/scripts/python/examples/hashizume.cif -osmi >> ============================== >> *** Open Babel Error in ExtractUnitCell >> CIF ERROR: missing a,b or c value - cannot interpret structure ! >> ============================== >> *** Open Babel Warning in ExtractSpacegroup >> CIF ERROR: missing spacegroup description: defaulting to P1... >> O=C(NC(=O)NCC)CCC(C)C 1-ethyl-3-(4-methylpentanoyl)urea >> >> Are these errors correct? I opened the file in Mercury and the entries >> have a,b and c values and a spacegroup of P-1. > > Well, the errors are correct: In this CIF file, there are *two* data > entries, "data_global" and "data_ethyl98K". > In the first (data_global) there are just journal and author > information, and no crystal structure - which causes the errors. > > The second data entry (data_ethyl98K) has all the correct information, > and is interpreted correctly without warning - this gives the structure > output. > > If you remove the "data_global" entry the error disappears. > > In a CIF file there may be a number of independent data_** entries, > any of which may or may not contain a crystal structure, or diffraction > data,. OB currently tries to interpret all the data entries. > > This raises the question of what should OB do in such a case: simply > ignore, or a warning, or an error... > At the very least the message could include the name of the data > statement, and say something less ominous like: > "while reading the data_global , the following error was encountered: > missing a,b or c value. > This may be caused by a non-crystallographic data_ field". > > Alternatively, data_ entries without any apparent structure information > (no cell, spacegroup or atomic positions) may also be ignored, or just > issue a warning > > What do you think ?
It's up to the xtalographers on the list (speak up!). Google says that data_global is not part of the official standard but it is often used in any case. The thread at http://www.mail-archive.com/jmol-users@lists.sourceforge.net/msg07178.html tells us what Jmol decided to do: "Bob proposed not to ignore data_global blocks, as I suggested, but to check if they contained structural data, which is a better idea.". If you google some more, you might find some more advice. - Noel ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
