[sdpd] Re: : Use of CIF as advocated by Lachlan

[Robin Shirley <R.Shirley... @surrey.ac.uk>]

[Re-sending, as my mailer keeps reporting problems and I'm not sure whether 
this is getting through - my apologies if this leads to duplicate copies]

Lachlan Cranswick writes [Mon, 8 Nov 1999 16:05:18 +0000 (GMT)]:

> For a sizable database, I don't see an alternative to CIF
> for being able to transfer Crystallographic structure
> and data information in a civilised manner (?)
> (compared to having a dozen or so different formats where
> things could become a mess quite quickly).   If not CIF,
> then what?

If what we require is a single common file format that must serve many (only
partly compatible) uses, this is probably true.

I think much of the difficulty arises from CIF being conceived primarily as a
*publishing* format (i.e. output-only), so that it does not very efficiently
serve the needs of other tasks that involve both input and output.

Other specifically powder-related issues perhaps derive from the fact that CIF
was designed in the first instance as a single-crystal format, with extensions
to Powder CIF added subsequently, after the main design features had been
fixed.

Powder datasets tend to be less stereotyped than single crystal ones, and so
call for more types of CIF term to capture their variations.  However the CIF
committee seem to have felt (with some reason) that single-crystal CIF had
already become over-complex, so that they were reluctant to admit Powder-CIF
extensions on equal terms with those already included for the esoterica of
single crystal work.

In my experience the CIF committee attitude, in so far as it has filtered
through to me, tends to be that matters that are *specific* to powders can't
really be very important, and so can safely be relegated to general comment
fields (where of course they are no longer required to be either clearly
formatted or machine-readable). 

> On the single crystal side, Louis Farrugia's CIF conversion
> software is very solid; showing good CIF conversion can be done,
> both in converting "structure" and "reflection" data into
> WinGX's shelx format.
>     http://www.chem.gla.ac.uk/~louis/software/
>     http://www.ccp14.ac.uk/ccp/web-mirrors/farrugia/~louis/software/
>     http://ccp14.sims.nrc.ca/ccp/web-mirrors/farrugia/~louis/software/
> 
> How much programming effort (hours, days?) would it considered
> standard to be able to program in a CIF to X converter for
> say GSAS or Fullprof, or X?  Is any source code available that
> could be used as a template for powder authors?
> 
> Is there any instance of a powder program being able to
> import a CIF into the program's native powder format?

In order to overcome some of CIF's shortcomings as an input medium for powder
data, and so hopefully to combine the benefits of commonality with those of
efficiency and appropriateness, I agree that the answer probably lies in
implementing CIF-to-X converters, as Lachlan advocates.

CRYSFIRE probably does not provide a good example, since its input needs are
so minimal that the mismatch with CIF's elaboration is particularly striking.

Nevertheless, let's consider what would be needed.

While it would not be very difficult to get CRYSFIRE to read the same basic
subset of Powder CIF that it writes, it would be considerably harder to get it
to extract the same information safely from the bulky, baroque structure of a
full CIF.

One major, specific problem is that CRYSFIRE requires a peaks-list in the form
of either 2Theta, d or Q (= scaled 1/dsq), while the CIF might well only
contain profile data, without any peaksearch output.

However, that could be handled with some form of freestanding CIF-to-X
converter that could pipe its results into a peak-extraction routine,
especially if the latter could output WinFit or XFIT peaklists, as CRYSFIRE
already includes input filters for both of these.

Or (which amounts to the same thing) an existing profile-handling program like
FULLPROF could be enhanced to both read CIF profile data and to output CRYS
datasets.

In general, the provision of file-format converters is a very valuable
service, greatly appreciated and to be encouraged, especially if they are not
just left as ad-hoc individual programs but are linked in some overall
framework that permits them to be pipelined together (as indeed are CRYS and
QDAT within CRYSFIRE).

Robin Shirley
School of Human Sciences
University of Surrey
UK