Pam, as the author of the INP format it was not my intention to make your life difficult.
Maybe I am wrong but is it the case that we are now supposed to write into CIF more than just primary/raw data. This to me is not what was originally meant for CIF; non-primary data such as logical statements and looping constructs need a script. Before stoking the fire I will say that I am not an expert in the field of archiving but maybe thats why I may be able to contribute to the discussion. A long time ago I briefly read the CIF documents and thought that it was more about helping journals incorporate data into papers than it was about storing non-raw information. It does of course help data exchange as it is a standard (supposedly). CIF at the time of inception was no doubt a step forward but in todays computing world the idea of data being separate to a document is fast coming to an end. Not joining a fad can be wise but how can one level of looping in CIF be sufficient (someone correct me if things have changed). Even though the INP format is similar to XML without the tags it is not my preferred option either. XML however is far superior to CIF especially when combined with something like JScript. It can describe any document and at any complexity but it can be cumbersome when things get complex. In extreme cases nothing beats a script or dare I say a programming language. I dont know how many readers know of the Mathematica journals but it is the ultimate in combining non-raw data with document. This leads me to my preferred option! Why not use something like c or c++; and dont say that its not possible as its relatively easy to convert INP format to c++ with the use of operator overloading and it would look just as simple. Why cant a CIF file be a c++ file with associated standard headers predefined (analogous to a dictionary); is it because c++ is too complex maybe but gosh arent we scientists. There are tools coming online that allow the viewing of c++ class hierarchies together with its data whilst a programming is running. One such OLD tool I stumbled upon during a stint at ISIS is the open source ROOT which allows the browsing of c++ classes and its data in a GUI friendly manner whilst a program is running; this is analagous to an XML browser. There are other commercial ones not to mention any good debugger with the nicest of GUIs. Thus your 'checker' would in fact be a c++ compiler (interpreter or otherwise) and I cant think of a better standard. Pie in the sky! Well please explain why? I am willing to bet that such an approach would be superior to XML and the learning of the c++ syntax simpler than XML. All the best Alan Coelho -----Original Message----- From: Whitfield, Pamela [mailto:[EMAIL PROTECTED] Sent: Thursday, 13 July 2006 12:06 AM To: rietveld_l@ill.fr Hi Bob This was a solution from scratch so I'm afraid I was using Topas 4. It will output the structural CIF file and stuff like reflections, calculated patterns and whatnot into text files, but none of the other various bits and pieces. I had to do those by hand. The CIF checking seems to have particular trouble handling all the different residuals, i.e. overall, individual patterns, etc and it really doesn't like splitting the RB into the different phases. As far as I can tell they are all there, in the correct places, but CheckCIF doesn't find any of them. Trying to deal with convolution peak fitting is a little difficult, as there's nothing like PV parameters to input. I had to be very vague on that indeed. Topas also doesn't use the standard absorption corrections. CheckCIF didn't manage to extract the structure data. The Platon check did (a little weird as I though they were supposed to be equivalent), but believe it or not it got the Z wrong for the silicon standard so messed up the checking! I think I've taken it as far as I can go so it will have to do. I'll just have to explain that CheckCIF made some mistakes. The next file I have to make is from a Topas analysis as well. I'm not sure any other program could handle the constraints I constructed for that one (how's that for being controvertial?!). I'd be curious to see if CIF could handle the geometrical constraints that have been published recently in J.Appl.Cryst. on apatites (I have to admit to some involvement :-). For that one no CIF was created but the Topas input file was deposited. Maybe I should have done the same here! The template idea is a good one. Unfortunately I seem to be doing all sorts of analyses which aren't directly related to each other from different instruments, so a template for this one won't help with the next one, which also involves user-defined instrument convolutions - what joy! Pam -----Original Message----- From: Von Dreele, Robert B. [mailto:[EMAIL PROTECTED] Sent: July 12, 2006 8:49 AM To: rietveld_l@ill.fr Pam, Actually what was the issue with the cif files with multiple phases/data sets? gsas2cif writes it out fine, I presume. Is it that the cif checkers can't handle the complexity? I guess my comment is that they'd better as there is going to be a lot more of this kind of thing in the future. Even mmCIF will need to adapt to this (that's a one data set only system). For the cifer's - are there fundamental design issues in cif that makes this a problem? Can cif adequately deal with the multiple histogram (x-ray, neutron, single crystal, powder & restraints all mixed together) capabilities of GSAS? Pam, as you probably know, gsas2cif writes out template cif files which you can "edit once" and reuse. Would this help your problem? Bob ________________________________ From: Whitfield, Pamela [mailto:[EMAIL PROTECTED] Sent: Wed 7/12/2006 6:23 AM To: rietveld_l@ill.fr Vincent and co Unfortunately I don't yet have the software to do a real VCT data-collection (not sure many people do, hence 'VCT-type'). Until I can do it properly, the best I can do is chop the pattern up into pieces with different count-times (and sometimes step-size at high angles), and treat them as multiple datasets :-( Easy enough to deal with in the refinement but more than a couple gets clumsy to deal with in the CIF.... This is the first one of these files I've had to make up, and because I intend submitting to a IUCr journal I can't skip too many of the fields (which includes the data, calculated, reflections, etc, which do work BTW). To cover all my bases I've put this through every CIF-editing/checking piece of software I can get my hands on. Some of them give no errors whereas some light up like a Christmas tree, e.g. Platon. Next week I have to make another file with resonant diffraction and neutron data thrown in with anisotropic broadening and some very complex occupational constraints - I have to say that after this experience I'm not looking forward to it, although that one will be going to Elsevier so maybe they won't miss a few terms! Pam ________________________________ From: Favre-Nicolin Vincent [mailto:[EMAIL PROTECTED] Sent: Wed 12/07/2006 5:30 AM To: rietveld_l@ill.fr Hi, On Tuesday 11 July 2006 19:13, Whitfield, Pamela wrote: > After spending over 2 days making up a single file, I'd like to hear > some other opinions on the practical aspects of CIF files for > structures from powder data. This is partly a moan from trying to get > a 11000 line file to pass the CheckCIF when all of the items it > complains about are actually there from what I can tell. Although > optimizing data collection using VCT-type approaches is nice from a > statistics point of view, it's absolute hell when it comes to creating > the CIF file, and multiple phases just piles on the grief. I almost > wish I hadn't bothered with the internal standard. As for VCT, is there really a specific need to write everything ? The only useful information is, for each point "2theta (or d or t), Iobs and sigma(Iobs)". After all, the 'VCT' information is entirely included in sqrt(Iobs)/sigma(Iobs), which can be constant or not, so why bother writing the exact counting time for each point, even if the powderCIF dictionnary allows it ? Vincent -- Vincent Favre-Nicolin CEA/Grenoble http://www-drfmc.ceng.cea.fr/ DRFMC/SP2M/Nano-structures et Rayonnement Synchrotron 17, rue des Martyrs 38054 Grenoble Cedex 9 - France tél: (+33) 4 38 78 95 40 fax: (+33) 4 38 78 51 97 -- Vincent Favre-Nicolin Université Joseph Fourier http://v.favrenicolin.free.fr <http://v.favrenicolin.free.fr/> ObjCryst & Fox : http://objcryst.sourceforge.net <http://objcryst.sourceforge.net/>
