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/>
