CRYSFIRE

Crysfire.
rtf Robin Shirley

V4.06 2 August 2002
User Manual
The Crysfire 2002 System for Automatic Powder Indexing
A Powder-indexing wizard in the form of a family of DOS scripts and programs

for running indexing programs automatically
(including scripts for running from Qdat data file formats)
[Formatted for a Postscript printer in 10pt Times New Roman, and saved in Rich Text Format by MS Word as Crysfire.rtf]
1. Introduction to Crysfire 2002 and its New Features

One of the barriers to the current renaissance in ab initio structure determination from powder diffraction is the stubborn
fact that, before structural work can be done on a material that is only available in powder form, its unit cell must be
determined.
Unless the powder pattern can be indexed, the intensity associated with each reflection cannot be assigned to its location in
reciprocal space, and further progress is impossible. With recent advances in methods for structure solution from powders,
and especially in Rietveld refinement, this initial indexing stage is increasingly the main bottleneck in determining powder
structures.
Though the unit cell completely determines the powder pattern (with intensities, instrumental factors, etc.), this is not logically
reversible, since we can only resolve a relatively small, degraded and partly overlapping portion of the pattern that lies near the
origin of reciprocal space. Powder indexing involves a complex process of induction that is far beyond manual methods in all
but the simplest cases. Fortunately, there exist powerful and mature indexing programs, with intelligent front-ends and expert
systems to assist the non-specialist in using them.
One of the most widely used of these is Crysfire. Despite its relatively unsophisticated interface, Crysfire continues to bring an
unparalleled range of heavy-duty indexing software to non-specialist users. Eight programs contributed by various indexing
specialists were included in its August 2000 release, including some not readily available elsewhere, plus a large toolbox of
support facilities.
One of the central features was the generation of a log-file and a cumulative summary file for each dataset, which builds up as
the investigation progresses, and shows a line-per-solution summary of each trial cell found by the various programs, sorted
into descending order of lines indexed and figure of merit.
However, the Crysfire 2000 core was up against compiler-address-space limits. This new release, Crysfire 2002, has required a
port of the core to a different language (Turbo Pascal, with the intention of migrating in due course to Delphi under MS
Windows and Kylix under Linux), giving a largely rewritten version that has been completely revised internally and contains
four times as many bytes of source code.
Crysfire 2000 users will find that the front-end interface largely remains familiar (since ability to reproduce the output from the
previous version was used as a criterion of correctness), but the new Crysfire is now a close-coupled system, faster, more
robust and easier to use. Nothing has been lost and there are several powerful new facilities.
All facilities can now be run directly from the main command menu, including programs that previously would only run as
standalones. Another new feature is that on restarting Crysfire in a particular data directory, the most recently used dataset will
automatically reload.
The online help has been redesigned and extended, supported by a clearer and more comprehensive manual (twice the size of
its predecessor). All documentation for Crysfire and its supported indexing programs can now be viewed directly from the
Crysfire command menu using new VM (View Manual) and VF (View File) commands.
Although Crysfire 2002 will take advantage of many of the facilities of Windows when it finds itself running in that
environment, it is still essentially a DOS suite, designed to be able to run on almost any PC anywhere in the world, including
the rather basic equipment that may be all that is available to students in developing countries. Of course, since indexing can
be a computationally intensive process, Crysfire will be seen at its best when running at GHz speeds on a modern Pentium or
1
Athlon PC, under Windows 95 or later. Nevertheless, it will still get there eventually on any PC that meets its very basic
requirements (640K RAM, a hard disk of some sort and DOS 5 or later).
An obvious change, and hopefully an improvement, is the new IN (=index) command, which launches indexing programs
directly (including Mmap - see below), automatically reloading the current dataset on returning (this cycle was previously a
little clumsy and required several user commands).
All previous indexing programs are supported (often with considerable improvements), plus a completely new program Mmap,
which can be used both for ab initio indexing and for topographical scans of solution space, since it generates a visual colour-
contoured map of the hills and valleys of figure of merit plotted against lattice parameters.
For example, consider the case of the figure-of-merit surface surrounding a trial solution for a triclinic biological material,
made more difficult to index by a dominant zone and very small particle size (producing some line-broadening). The dominant
zone generates numerous mathematically-possible solutions, many of which might be plausible if the only criterion were
refined figure of merit.
Section C: alpha* [Q(D)] across (77 to 73), beta* [Q(E)] down (82 to 80)
82.0 5 5 5 5 5 6 5 5 5 5 5 5 5 5 5 6 5 5 5 5 5 5 5 5 5 5 4 4 4 4 4
81.9 4 5 5 5 5 6 6 5 5 5 5 5 6 6 6 6 6 6 6 6 6 5 5 5 5 5 5 4 4 4 4
81.8 4 5 5 5 5 6 6 6 6 5 5 6 6 6 6 7 7 6 6 6 6 6 5 5 5 5 5 5 4 5 5
81.7 5 5 5 5 5 5 6 6 6 6 6 6 6 7 7 7 7 7 6 6 6 6 6 5 5 5 5 5 5 5 5
81.6 4 5 5 5 5 5 6 6 6 6 6 6 7 7 8 8 8 7 6 6 6 6 6 6 5 5 5 5 5 5 5
81.5 4 5 5 5 5 5 6 6 6 6 7 7 7 8 9 9 9 8 7 7 7 7 6 6 6 5 5 5 5 5 5
81.4 4 4 5 5 5 5 6 7 7 6 7 8 8 91010 9 8 7 7 7 7 7 6 6 6 5 5 5 5 6
81.3 4 4 4 5 5 5 6 7 7 7 7 8 910101110 9 8 7 7 7 7 6 6 6 5 5 6 6 6
81.2 4 4 4 5 5 5 6 6 7 7 8 8101112131210 8 7 7 7 7 7 6 6 6 6 6 6 6
81.1 4 4 4 5 5 5 5 6 7 7 8 9101215161311 9 8 7 7 7 7 6 6 6 6 6 6 7
81.0 4 4 4 5 5 5 5 6 7 7 8 910121621161210 8 7 7 7 7 7 6 6 6 7 7 7
80.9 4 4 4 5 5 5 5 6 7 7 8 8 9111317171310 8 7 7 7 7 7 6 6 7 7 7 7
80.8 4 4 4 4 5 5 5 5 6 7 7 8 8101112131311 9 8 7 7 7 6 6 6 7 7 7 7
80.7 4 4 4 4 5 5 5 5 6 6 7 8 8 91011111010 9 8 8 7 7 6 6 7 7 7 7 7
80.6 4 5 4 5 5 5 5 5 5 6 6 7 8 8 8 9 9 9 8 9 8 7 7 7 7 6 7 7 7 7 6
80.5 4 4 5 5 5 5 5 5 5 6 6 7 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 7 6
80.4 4 4 4 5 5 5 5 5 5 5 6 6 7 7 7 8 7 7 7 6 6 6 7 7 7 7 7 8 7 7 6
80.3 4 4 5 5 5 5 5 5 5 5 6 6 6 7 7 7 7 6 6 6 6 6 6 6 6 7 7 8 8 7 7
80.2 4 4 5 5 4 5 5 5 5 5 5 6 6 6 7 7 6 6 6 5 5 5 5 6 6 7 7 7 8 8 8
80.1 4 4 4 4 4 4 5 5 5 5 5 6 6 6 7 7 6 6 5 5 5 5 5 5 6 7 7 7 8 8 8
80.0 4 5 4 4 4 4 4 4 4 4 5 6 6 6 7 7 6 6 5 5 5 5 5 5 6 7 7 7 8 8 8
A merit-surface map, as shown above, provides a clearer picture in which the central peak reveals itself as likely to be a
physically correct solution because of its narrow and compact cross-section, while others (not shown), which are merely
pseudo-solutions, prove to lie on ridges and other extended features in solution space (in Mmap, this would be displayed
colour-contoured.).
The new M1 and M3 commands display the three principal topographic sections centred on the currently stored cell. M1
displays all three together as thumbnails within a single screen, while M3 displays three more detailed consecutive full-screen
views (of which the figure above is one example, using all-default parameters). A more general MM command generates
individual maps under more detailed user control. Mmap's indexing mode can also be accessed from the IN command.
A new LC (Load Cell) command allows trial solutions to be loaded from Crysfire or Chekcell summary files to simplify such
investigations. Since the next task is often to assess its topography maps, a shortcut into the M1/M3 map sequence is provided.
Another new feature is that, during indexing runs, after the summary file has been displayed, all solutions are run through a
system version of Ton Spek's Le Page program then redisplayed for comparison in reduced-cell form. This highlights the
relations between trial solutions, including those which are actually equivalent, though previously found in different settings
(and, equally important, those that are non-equivalent derivative cells, though their volumes might have suggested that they
were different settings of the same solution).
Also new is an approximate ab-initio volume estimate which is reported whenever a dataset is loaded, with a suggested rescale
factor if it seems likely to be outside the volume range for which most indexing programs have been optimised. This can
become important as SDPD attempts increasingly ambitious structures, even including proteins (e.g. a new form of zinc
insulin: Von Dreele, 2002).
At the other end of the scale, high-pressure/high-temperature experiments often unavoidably yield sparse datasets from phases
that are not observable under ambient conditions, and which contain fewer than the 20 observed lines regarded as the absolute
minimum by many indexing programs.
2
A new EP (Extend Pattern) command can automatically extend any sparse pattern by adding higher orders of observed lines
until the total has been expanded to 20. While this obviously cannot increase the amount of information present, it permits
more programs to run, providing a broader basis for hypotheses about the cell (or at least sub-cell) that is present.
Finally, the logfile has been made considerably more comprehensive, so that its record now acts more nearly as an automated
laboratory notebook for indexing work on each dataset name.
The author wishes to acknowledge, with thanks, all those who have contributed indexing and cell-transformation software to
the Crysfire 2002 system, especially Franz Kohlbeck, Daniel Louër, Ton Spek, Daniel Taupin, Jan Visser and Per-Eric Werner,
and also to draw attention to the fruitful symbiosis that exists between Crysfire and the Chekcell program by Jean Laugier &
Bernard Bochu, for graphically examining proposed solutions and investigating their probable symmetry.
Like its predecessor, Crysfire 2002 is distributed from the CCP14 website and is free for academic and other non-profit use (on
academic, personal and other non-commercial computer systems).
It can now also be licensed for industrial use (see the document file Licence.txt included in the distribution, the fee being
specifically for the overall system integration, the front-end, and for special software like Mmap – no charge is made for
contributed code). A separate, semi-automated 32-bit Windows version (Industrial Crysfire), usable by technicians and other
non-crystallographers, is in the development pipeline.
2. What is Crysfire and what does it do?

Crysfire is a system (or suite) of programs, held together by a set of interlocking scripts in the form of DOS batch files, so as
to behave in most respects like a seamless whole to its users.
Its role is to provide a toolkit to assist in the preparation and enhancement of powder diffraction peak data for use in powder
indexing, and especially to act as an expert system and wizard (in the Microsoft sense) to permit indexing to be carried out
relatively fast and painlessly by non-specialists.
As discussed above, Crysfire will run on almost any PC from an XT to the latest GHz Pentium or Athlon, though it will
obviously look its best on the latter.
Crysfire is actually the name of the launch script that bootstraps the system. It passes control to a master script, which runs the
front-end program CFmain. This in turn issues the Crysfire command prompt and provides the environment that users mostly
think of as Crysfire. To the user, all this happens instantaneously on a modern PC, so that the system seems like a single
unified program.
When an indexing command is issued, control passes to one of the subsidiary scripts, which will run a sequence of programs
that carry out the actual indexing and display its results, eventually returning to CFmain and the Crysfire command prompt.
This will be a fresh instance of CFmain with the current dataset automatically reloaded, ready for further commands.
Strictly speaking, "Crysfire" itself comprises the scripts, the CFmain front-end and a number of associated utilities, plus
various modifications and post-processors for the supported indexing programs, to enable them to co-operate within this
system.
Thus it does not properly include the indexing programs themselves, or at least not all of them, although they are normally
included in the Crysfire distribution package for convenience.
This distinction is worth making, because the suite as a whole contains indexing software that has been contributed by a
number of authors - contributions that are gratefully acknowledged. As author of the overall system, I must emphasise that I
lay no claim to this contributed code and specifically assert the copyright of the various indexing-program authors in the base
versions of their programs (including myself where applicable).
Thus the various indexing programs which are called via the IN (=INdex) command are either the authors' unmodified
binaries (e.g. Ito, Dicvol and Treor) followed by post-processors to extract the solutions, or modified and recompiled versions
(Kohl, Taup, Fjzn6, Lzon and Losh). Lastly, the new Mmap program is embedded in CFmain and called directly from the
Crysfire command prompt (as MM).
Does a user need to know any of this? Usually not. Hopefully it all works seamlessly together, allowing non-specialist
users to perform indexing operations on their datasets with a minimum of keystrokes and effort. By non-specialist I mean
non-specialists in powder indexing - they are still assumed to have some crystallographic knowledge and are likely to be
people engaged on structure determination from powder data, for whom indexing is simply a necessary but critical
preliminary to the main show.
3
3. Installing Crysfire
Crysfire can be downloaded from the CCP14 website in the form of a zipfile, and should be unzipped in its own directory
("folder" in Windows terminology) - the Crysfire "home directory". By default, this is taken to be C:\Crysfire, although
the actual name and drive is not fixed, so long as it is specified in the small script CF_Home which sets it in the DOS
environment. If C:\Crysfire is used as the home directory, no changes are required, otherwise its name will have to be
edited into CF_Home.bat.
Under all Windows (and DOS) versions except XP, the installation is then completed just by running the supplied script
CFsetup, which copies the two bootstrap script files (CF_Home and CFmaster) into the main Windows (or DOS) directory.
Under Windows XP, however, because changes to the Windows directory are not permitted (and automatically reversed),
the automated route via CFsetup is blocked, and the Crysfire home directory path has to be added by hand to the execution
PATH variable within the DOS environment (if the system has previously been running Crysfire 2000, it will already be
there).
The process of adding the Crysfire directory to the PATH is usually done by editing the PATH= line in the Autoexec.bat
file. If that would make the PATH line too long, one can also add a line creating a temporary PATH at the beginning of
the Crysfire.bat script, or in a preliminary call of a specially-written path-setting script, for those who know how to do such
things. Either way, this is not done automatically by any kind of install-wizard, but needs to be done manually using an
editor – I'm not happy with programs that mess automatically with the configuration of people's systems.
Once the Crysfire bootstrap scripts are on the PATH, Crysfire can be called from whichever directory contains the data to
be analysed. This is the recommended way to use it – having a separate directory or sub-directory for each problem, to
keep its housekeeping in good order.
Crysfire requires about 550K of base RAM (i.e. the bottom 640K of address space) to be free for programs to use - this can
be checked with the DOS Mem command. I've found that networked Windows/NT systems often have their base RAM
recklessly stuffed with network drivers, etc., in which case it may become necessary to reboot temporarily without the
drivers to make sufficient room available for Crysfire to run.
Crysfire makes heavy use of DOS environment variables to communicate between its subsystems, so also needs enough
free space for these. Preferably make sure of this by adding a suitable "shell=" line to Config.sys. For example, under
Windows 9x, this might be:
shell=C:\WINDOWS\COMMAND.COM C:\WINDOWS /e:2048 /p
Under DOS or Windows 3.x, substitute "DOS" for "WINDOWS". Under Windows ME, right-click on the Crysfire.bat
icon, then go to properties | memory | initial environment and insert 2048.
4. Indexing a Powder Diffraction Dataset (in CDT format) using Crysfire 2002
The procedure described below assumes that your dataset is already available in native Crysfire format as a .CDT file.
This can be achieved by either:
a) Typing it into Crysfire as 2Theta, Q or d, using the OBsinput command (only the first two letters are significant in
Crysfire commands – type Help, then C, to obtain lists of available commands in various formats).
b) Copying and pasting the appropriate list of values into the OB command via the Windows clipboard (this is often the
simplest method, unless you can import the data directly as in (c) below).
c) Importing it from the peaks list file generated by XFIT or Winfit, or from a Brüker EVA or Philips UDI file (using the
X2CRYS, WF2CRYS, EVA2CRYS or UDI2CRYS import programs included in the Crysfire 2002 distribution).
4
1) Start up Crysfire by either:
a) Opening a DOS prompt in your data directory and typing Crysfire (the recommended way). Under Windows XP,
this can be done conveniently by right-clicking on the data directory within Windows Explorer, then selecting
"Open a DOS prompt".
b) Double-clicking on the Crysfire icon (if there is one).
c) Via Start | Run (i.e. the Run option in the Start menu) and typing in "Crysfire".
If you use methods (b) or (c), you may need to do some switching of directories, which can lead to complications
when you launch indexing runs, so (a) is usually to be preferred.
The Crysfire banner heading should appear, followed by its command prompt: "Next command or HELP (or ?):". If
instead you see "Bad command or file name", make sure that the directory containing the Crysfire system is on the
DOS command PATH. If Crysfire displays a message about setting up appropriate resources, follow this advice, or
seek help from someone who can.
2) At the command prompt, type LOad (or just LO, in either upper or lower case since Crysfire commands are not case-
sensitive). You will be shown a listing of the available .CDT files in the current directory – use the DR command if
you need to change to another drive or directory, but be aware that you can only launch indexing runs from the
directory that you started from).
3) Type in the name of the dataset that you want to index (for example: Test) and press Enter. Press Enter again, if
necessary, to accept any defaults, until you have returned to the Crysfire command prompt.
A very approximate ab-initio volume estimate will then be reported - suggestions about rescaling will also be offered
if this is rather high. Similarly, advice about pattern-extension will be offered if you have a sparse dataset containing
less than 20 observed lines.
4) a) Type in the INdex command (i.e. IN), followed at the next prompt by the 2-letter code for the indexing program (or
shortcut code) that you want to launch (TP, D1, IT, FJ, TR, KL, D2, LZ, MM, DV, LS) or EX to exit back to the
Crysfire command prompt, and ? for help and advice. This will start up the indexing-wizard dialogue for that program
- read on for some advice about which program to choose.
b) A possible systematic order in which to apply these is broadly that shown in the list in (a) above, and as summarised
in the indexing online help (obtained by typing "?"):
i) First screen for high symmetry crystal systems (cubic, tetragonal, hexagonal) with Taup (TP) and Dicvol91 in its
high symmetry mode 1 (using the shortcut code D1).
ii) Then try the zone-indexing programs Ito12 (IT) and Fjzn (FJ), since these are powerful and very fast, and also
relatively resistant to spurious lines.
iii) Other reasonably fast programs for any crystal system that might follow are the index-space programs Treor90
(TR) and Kohl (KL).
iv) The Dicvol91 low-symmetry mode 2 (shortcut code D2) is efficient for low-volume cells down to monoclinic, but
may require several minutes and does not permit any impurity lines.
v) The combination heuristic program Lzon (LZ) specialises in the pathological dominant-zone case, and usually
finds numerous low-symmetry solutions that other programs miss. Lzon is always well worth trying, though it too
may take several minutes, since it will sometimes unexpectedly reveal the existence of relatively high-merit
solutions after other programs have failed to come up with anything plausible. Its output also provides basis sets
that can be used with Mmap and Losh - it now writes a basis-set list (BSL) file that Mmap will load automatically.
vi) Mmap's indexing mode is flexible, if relatively slow - 5 to 15 minutes for a full scan, though unlike Lzon this is
not affected by excluding possible impurity lines. The overall visual appearance of the resulting merit-maps can
also be used to identify datasets with pathological problems that may not be worth pursuing without further
experimental work.
5) After selecting an indexing program, you will be asked how many of the observed lines to use – press Enter to accept
the default (this is generally a safe response to most Crysfire prompts that don't call for information that is specific to
your run, like the dataset name).
6) You will then be asked whether you want to accept all the applicable default responses, for an express route through
this section. This is usually the best option for an initial run, so press Enter to accept it.
7) The express route will jump you forward to a question asking whether you want to change the 2Theta zero correction –
press Enter for "no change" (if it does need adjusting, consider restarting and using Crysfire's self-calibration facilities
for Z2Th or specimen-displacement via the main-menu SC command, or specifying a zero correction directly via ZE).
5
8) You will next be asked to confirm (or change) the filename (i.e. dataset name) to be used for this indexing run, and its
one-line descriptive title. Usually it will be OK to press Enter to accept the defaults for each of these.
9) You should see a message saying that the Qdat input file has been successfully written to disk, and asking you to press
Enter to continue. The indexing run is then automatically launched (unlike in Crysfire 2000, where users first had to
QUit the front-end manually).
10) The indexing program itself will immediately start executing – in the case of Ito12, this should be finished in under a
second on any modern PC. At the next prompt, press Enter to see Ito's short output file in an editor of your choice
(default: WordPad under Win9x, etc. or Edit under DOS – these can be changed by specifying some other editor in the
INDEXEDIT environment variable).
11) Scroll through the indexing output file and see whether the run appears to have been successful – (Control-End
followed by one or more PageUp(s) will take you straight to a summary table near the end of the file).
12) A solution with reasonably low cell volume (for the kind of sample that you are investigating) and which indexes all or
nearly all of the first 20 lines, with a good figure of merit (i.e. 20 or better, and 50+ with a modern focusing
diffractometer), would be considered very promising.
The high-quality "Test" dataset converges to the same 648 A3 cell that indexes all the first 20 lines, for each of the four
best solutions (obtained from different combinations of zones). The first has a figure of merit of 113.8, the remaining
three all have 55.9 – the reason for this factor-of-2 difference being that the first had already taken into account a
proposed C-centred Bravais-lattice, which approximately halves the number of calculated lines needed to account for
the observed pattern. Although the other three also report a C-lattice, their lower figure of merit shows this to have
been detected only during the final round of refinement, too late for its greater parsimony to be taken into account in
the figure of merit.
13) The solution(s) may also be checked by looking for evidence of systematic absences that might suggest a reasonable
spacegroup. Immediately before the summary table there will usually be a table of the observed lines and their
suggested indices, for one or more of the best four solutions. Evidence of absences that suggest screw axes and/or
glide planes is another indicator of probable correctness.
14) Exit by issuing the appropriate command (for WordPad that's Alt-F4; for DOS Edit, it is Alt-F, followed by X) - a
brief progress message (or diagnostic) will then be displayed. Press any key (e.g. Enter, or Alt-F4) to move to the next
editor display, which will be of the updated Crysfire summary file.
This contains all the solutions suggested so far for this dataset during Crysfire indexing runs, in the form of a line-per-
solution display, sorted first on number of lines indexed in the first 20 (I20), then subsorted on figure of merit (as
defined by each program). If no sufficiently good solutions have been found, the analysis will be halted at this point
and you will be asked to press any key to restart at the main Crysfire prompt.
Let us assume that this is not the case, and that Ito has found some solutions. At this stage, having run only one
program, the summary list will only contain the four solutions from Ito12. You can see more of each line by scrolling
to the right (each line of text may be up to 232 characters long, though the most important columns for assessing
solutions are in the leftmost screenful which is thus visible by default).
15) a) A useful parameter to check is V/V1 – the ratio of the volume of each proposed cell to that of the cell currently at
the top of the list, and hence likely to be the best solution so far. This makes it easy to identify solutions that are likely
to be alternative settings of the best solution because they have exactly the same volume (V/V1 = 1.00), and similarly
any derivative cells with integer multiples of the volume (e.g. V/V1 = 4.00, etc.).
b) Other useful items include BL (the Bravais lattice type) and Pedigree (which provides an audit trail back into the
indexing output files, to allow one to trace how that particular solution was obtained).
16) Again use the appropriate command to exit, as in step (13) above, then press any key to run the Le Page reduced cell
program on each solution in the summary file and move to the next editor display.
17) This will show a revised reduced-cell summary table, which lists the Niggli reduced cell for each solution, and shows
its V/V1 ratio to that of the top solution. Scroll right to see the original cell, with a V/Vreduced ratio showing what
multiple of its own reduced cell that solution was.
This display can be informative about the relations between the various solutions. The reduced-cell process is a purely
geometrical one - cells with identical reduced cells will generate exactly the same lattice and are actually the same cell,
though possibly in different settings.
6
Cells with different reduced cells but some integer relation between their volumes are very probably derivative cells of
each other - for example, sub- or super-cells.
Since the reduced-cell process knows nothing about systematic absences, it will show different choices of Bravais
lattice for the same cell as different reduced cells, since they generate different sets of reciprocal lattice points -
typically with the reduced version of the primitive cell having twice the volume of that for the centred cell (since the
primitive one cannot be reduced further).
18) You will then be returned to step (4) above, with the current dataset automatically reloaded (another advance over
Crysfire 2000) to launch another indexing program. The Crysfire 2002 INdex command supports 9 programs - 7
fully-automatic ones, plus Losh and Mmap (in indexing mode) which both require some user guidance.
In each case, the results will be merged and sorted into the summary file, to augment those already obtained.
Each program has its strengths and specializes in particular types of pattern, though all will succeed convincingly with
a straightforward, high-quality pattern like Test (a Y2(oxalate)3.2H2O oxalate complex measured in Daniel Louër's
laboratory, provided with his kind permission). If the same solution is found by several programs, this increases one's
confidence that it may be correct.
19) Another criterion that can help to indicate whether or not a trial solution is a good candidate for the actual physical cell
is the topography of the three central sections through the solution in the figure of merit surface.
These can be displayed as comparative thumbnails within a single screen by the new M1 command, and as three more
detailed consecutive full-screen maps by the associated M3 command.
A good candidate will usually show a compact round or star-shaped peak in all three of its central sections, standing
out clearly from the surrounding surface, while a solution that is merely the highest point on a ridge or other extended
feature (in one or more of its sections) should be considered as suspect. These rules are not foolproof, but they
provide some useful additional criteria for evaluating trial solutions.
20) The Laugier & Bochu Chekcell helper program is recommended for further evaluating the various solutions found and
their settings (see section 11).
Crysfire 2002 can be downloaded free for non-profit use from the CCP14 website (www.ccp14.ac.rl), where Lachlan
Cranswick has provided an online tutorial. It can also be licensed to industrial users - a pro-forma invoice is provided (as
discussed earlier, this is for the use of the system as a whole and its integrated features). Chekcell is also among the many
useful programs available from this site - see the last page for references.
7
5. Crysfire Commands
The following Crysfire commands can be issued from the main command prompt, which appears as follows (allowing for
the particular version of Crysfire in use)t:
Crysfire 2002 v9.45.14 - Next command or ? for Help:
Only the first 2 characters of each command (shown in capitals) are significant.
5.1 Overview of Crysfire commands listed alphabetically by command code

AB = Set Bravais lattice absences MS = Modify SUM file (merge/unscale)
CA = Calc pattern (and compare obs) OB = Input obs pattern (keyboard)
CE = Input/display/edit cell data OF = Copy to outfile (on/off)
CD = Directory/drive change PR = Copy to printer (on/off)
DI = (Launch direct-indexing run) QC = QCalc (for specified lines)
ED = Edit the observed pattern QM = QMax limit for calc pattern
EF = Write End-of-File to outfile QU = QUIT (from Crysfire)
EP = Extend Pattern to 20 lines RS = Re-Scale observed d-spacings
HL = Hlimits (set hkl min/max) RU = Run operating system command
IM = Import a peakslist file SA = Save dataset (Crysfire or CIF)
IN = Launch an indexing run SC = Self-calibration (Z2Th or T)
LC = Load cell from summary file TR = Transform obs 2Theta (linear)
LI = List the observed pattern VF = View a File (.SUM, .LOG, etc)
LO = Load Crysfire dataset VM = View Crysfire Manual (Win9x)
MM = MMap (map solution space) VE = Crysfire version/directories
M1 = MMap: 1 screen of thumbnails WA = Wavelength entry/change
M3 = MMap: Show 3 principal sections ZE = Zero correction in 2Theta
? or HE = HELP (general, commands, file)

QU = QUIT (from Crysfire)
5.2 Overview of Crysfire commands listed alphabetically by task/topic

Bravais lattice absences = AB Modify SUM file (merge/unscale)= MS
Calc pattern (and compare Obs) = CA Obs pattern input (keyboard) = OB
Cell data (input/display/edit) = CE Outfile copy (on/off) = OF
Directory/drive change = CD Printer copy (on/off) = PR
Edit the observed pattern = ED QCalc (for specified lines) = QC
End-of-File written to outfile = EF QMax limit for calc pattern = QM
Extend Pattern to 20 lines = EP QUIT (from Crysfire) = QU
Hlimits (set hkl min/max) = HL Re-scale observed d-spacings = RS
Import a peakslist file = IM Run operating system command = RU
Index: launch an indexing run = IN Save dataset (Crysfire or CIF) = SA
Index: (direct-indexing run) = DI Self-calibration (Z2Th or T) = SC
List the observed pattern = LI Transform obs 2Theta (linear) = TR
Load cell from summary file = LC Version/directory details = VE
Load Crysfire dataset = LO View a file (.SUM, .LOG, etc) = VF
MMap (map solution space) = MM View Crysfire Manual (Win9x) = VM
MMap: 1 screen of thumbnails = M1 Wavelength entry/change = WA
MMap: 3 principal sections = M3 Zero correction in 2Theta = ZE
HELP (general, commands, file) = ?, HE

QUIT (from Crysfire) = QU
8
5.3 Crysfire commands grouped by task category
Apply/change general settings Input/modify observed pattern
AB = Set Bravais lattice absences OB = Input an observed pattern

HL = Set Hlimits (hkl min/max) LO = Load Crysfire dataset, incl obs
QM = Set QMax limit for lines IM = Import a peakslist file
WA = Set wavelength ED = Edit the observed pattern
ZE = Zero correction in 2Theta LI = List the observed pattern
EP = Extend pattern to 20 lines
Load/modify/save unit-cell data RS = Re-scale observed d-spacings
SC = Self-calibration (Z2Th/T)
CE = Input/display/edit cell data ZE = Zero correction in 2Theta
LC = Load cell from SUM or CKM file TR = Transform 2Theta data (linear)
LO = Load Crysfire dataset, incl cell
SA = Save dataset (Crysfire or CIF) Perform indexing operations
MS = Modify SUM files (merge/unscale)
IN = Launch an indexing run
Calculate pattern, merit, lines DI = (Launch direct-indexing run)
MM = MMap (explore solution space)
CA = Calc pattern (compare Obs) M1 = Show 1 screen of Mmap thumbnails
QC = QCalc (for specified lines) M3 = Show 3 principal Mmap sections
Job management
RU = Run an operating system command

SA = Save dataset (Crysfire or CIF)
QU = QUIT from Crysfire
Housekeeping, printing
CD = Change default directory/drive

VF = View a file (.SUM, .LOG, etc)
MF = Modify SUM files (Merge/unscale)
PR = Copy output to Printer (on/off)
OF = Copy output to outfile (on/off)
EF = Write end-of-file to outfile
VE = Show Crysfire version details
Help, information
?,HE = HELP (general, commands, file)

VM = View Crysfire Manual (Win9x only)
VF = View a file (.SUM, .LOG, etc)
VE = Show Crysfire version details
LI = List the observed pattern
CE = Display/edit Cell Data

9
5.4 Crysfire commands: expanded descriptions (alphabetical by command code)
AB = ABsence = Set the Bravais lattice absences Flag
CA = CAlcpat = Calculate a pattern (and compare with observed if present)
CE = CEll = Input/display cell constants (Direct, Q, Delaunay)
CD = ChgDir = Change the default directory/drive for datasets
DI = DirIndx = Launch a direct-indexing run using an edited input data file
ED = EDit = Edit the observed pattern (Insert, Delete, Change, Finish)
EF = EndFile = Write an End-of-File marker (ctrl-Z) to the output file
EP = ExtPat = Extend a sparse Pattern to 20 lines by adding higher orders
HL = HLimits = Set Hlimits for calc patterns (hmin,hmax,kmin,kmax,lmin,lmax)
IM = IMport = Import dataset from peakslist file (EVA, UDI, WinFit, Xfit)
IN = INdex = Launch an indexing run (ITO, DICVOL, TREOR, KOHL, LZON, etc)
LC = LCell = Load a trial cell from a Crysfire or Chekcell summary file
LI = LIstobs = List the observed pattern (and apply a zero correction)
LO = LOad = Load a Crysfire (CRYS) Dataset, previously saved by SAve
MM = MMap = Explore solution space using heuristic M-Maps (save peaks)
M1 = Maps1Th = Display screen of Mmap thumbnails (3 sections, all defaults)
M3 = Maps3 = Display sequence of 3 principal Mmap sections (all defaults)
MS = ModSum = Modify summary files (unscale or merge summary files)
OB = OBsinp = Input an observed pattern (as 2Theta, sinsqth, Q or d)
OF = OutFile = Select/deselect copying the output stream to a file
PR = PRinter = Select/deselect copying the output stream to the printer
QC = QCalc = Calculate Q (=10000/dsq) for specified lines
QM = QMax = Input a Qmax limit for the calc pattern (default Qobsmax+50)
QU = QUit = Exit from Crysfire (and launch any waiting indexing run)
RS = RScale = ReScale observed d-spacings by changing the assumed wavelength
RU = RUn = Run an operating system command, external program, etc
SA = SAve = Save the current dataset (as Crysfire .CDT format or CIF file)
SC = SCal = Zero-2Theta or specimen-displacement correction by self-calibration
TR = TRans = Transform 2Theta obs data by applying a linear equation
VF = ViewFile= View a file (.SUM, .LOG, etc)
VM = ViewMan = View the Crysfire Manual (Windows 9x and higher only)
VE = VErsion = Show the Crysfire version and directory details
WA = WAve = Input a wavelength in Angstroms (or CU for CuKalpha1)
ZE = ZEro = Input a zero correction in 2Theta (2Thcorr=2Thobs+Z2Th)
? = HELP = Help: general/input, commands, CRYS dataset file format)

6. Technical Information
Some more detailed notes follow for the Crysfire powder-indexing system, which comprises a master script with eight pairs of
subsidiary scripts, plus numerous associated programs, documentation and examples.
Crysfire runs nine of the principal powder-indexing programs automatically under MSDOS (either directly or from a Windows
DOS prompt), normally taking their input data from a standard Crysfire dataset, which can be typed directly into Crysfire (OB
command) or, more usually, loaded via the LO command after being imported by one of the available conversion programs
such as XF2Crys. For experienced users it is also possible to run the programs directly from hand-edited datasets in a Qdat
input file, or in that indexing program’s native input file format via the DI command (but only in the presence of the rest of the
Crysfire 2002 system, due to its close-coupled design). [For background on powder indexing in general, see Kyotindx.wp1.]
The present distribution includes the CFmain program (which acts as an interactive front-end and indexing wizard), the various
indexing programs, other associated programs, a quantity of documentation and example runs, and four programs (WF2Crys,
XF2Crys, UDI2Crys and EVA2Crys) for importing data from peaks-list files written respectively by the profile-fitting
programs WinFit and XFIT, from Phillips UDI files and from Bruker EVA output files. Crysfire 2002 can only use powder
diffraction data in the form of line positions and does not support profile data directly.
As mentioned, the subsidiary Q2{indx} scripts require Qdat-format input files. These will typically have been written by
CFmain in the course of a Crysfire run, from information provided interactively in answer to questions about the number of
lines to use, etc, (for which it’s usually satisfactory to accept the defaults offered).
10
In the actual distribution, all its Q2{indx} script files will have a suffix of the form _xx where xx is a distribution number, as a
mechanism to ensure that old versions, which do not match the current distribution, cannot be called inadvertently.
Direct-indexing runs from an indexing program's native-format input data files are also supported. These will usually have
been written by Qdat, in the course of a previous run of Q2{indx} under Crysfire, and then hand-edited to adjust special
features of the indexing program(s) concerned. This is equivalent to the RUN{indx} mechanism in Crysfire 2000 and earlier,
which was not widely used and is not compatible with the design of Crysfire 2002, so that it had to be withdrawn and replaced
by a new mechanism in Crysfire 2002 (via the DI = Direct-Indexing command) which allows native data files to be launched
directly from the Crysfire command menu.
For both mechanisms, the systematic file naming conventions used throughout are those of the overall Crysfire script system to
which all these scripts belong. Thus, on exit, a Crysfire run with that indexing program as its target will automatically leave
suitable data files in both the above formats within the working directory.
Each of the Q2{indx} scripts described here will automatically run the target indexing program, leaving the resulting output
file displayed (in brief form if available) in the editor specified in the environment variable INDEXEDIT (default: MS
WordPad under Windows 9x or later, DOS EDIT under DOS and Windows 3.x - the display of such files is omitted completely
if INDEXEDIT=NONE).
In order to run one of the target indexing programs successfully, the programs and scripts involved must be sufficiently recent
to support the facilities needed. Thus, for example, for LZON and LOSH to be supported as Qdat targets, the Qdat version
used must be at least v6.28k (i.e. Qdat628k). This should be the case for all programs in the current distribution.
In general, one should always update all the programs and scripts together from each Crysfire distribution as it becomes
available. The scripts and programs from a particular distribution are aimed to be the latest versions available at that time, and
are designed to work together. While this can never be completely guaranteed in the wonderful world of computing (and any
warranties of suitability for a particular purpose, stated or implied, are hereby disclaimed), installing all the executables from a
particular Crysfire distribution together is a good way to minimise one’s compatibility problems.
Note too that the Crysfire executables are required to be installed into a single directory - the Crysfire Home directory (by
default, C:\Crysfire). Its pathname is planted in the environment by a short script CF_Home.bat, which, together with the
launch script Crysfire.bat, needs to be on the DOS execution PATH.
Under all operating system versions except Windows XP, this will be done automatically if you run the supplied script CFsetup
from the Crysfire home directory. Under Windows XP (because changes to the Windows directory are rejected), you will need
either to modify AUTOEXEC.BAT to add the relevant directory to the PATH automatically, or run a small preliminary script
to do this before each Crysfire session. See the relevant file Install.txt or XPinstal.txt for further details.
Finally, note that Crysfire depends absolutely on being able to create a number of MSDOS environmental variables through
which the different parts communicate with each other. If you don’t have enough free space allocated for environmental
variables, you’ll get an “Out of Environment Space” message and Crysfire will be unable to complete its run. In that case, the
allocation will need to be increased, using a SHELL line in CONFIG.SYS - hopefully, Crysfire will have displayed brief notes
on how to do this.
All indexing programs called within Crysfire produce log and summary files, summarising the results obtained so far for the
specified dataset by that program. Cumulative log and summary files are also built up for the dataset as a whole:
{datafile}.LOG and {datafile}.SUM respectively. The logfile for each run is appended to the overall one for the dataset, and its
solutions summary added to that for the dataset then sorted into descending order of I20 and Merit.
The minimum levels for inclusion vary for different indexing programs, but are typically I20 above 15 and Merit above approx.
7 to 9, where I20 is the number of “indexed” lines in the first 20 observed lines, and Merit is based on De Wolff’s M20 but
calculated for “indexed” lines only (as interpreted variously by each indexing program). Note that the solutions listed are
simply a verbatim record of what the indexing programs have found, and make no claims either to be correct or to have been
expressed in the most appropriate crystal systems or settings. Such judgements are left to the user.
At the end of the indexing run, first the short output file, and then the sorted solutions summary, are displayed using the editor
specified in environmental variable INDEXEDIT (default: WordPad or DOS EDIT, depending on the operating system).
11
6.1 Indexing Programs Supported by Crysfire
The following indexing programs are supported in the current Crysfire distribution (with the latest version tested shown in
column 2). The version information refers to the local version used within Crysfire, and adapted and extended to run within
that environment and support Crysfire facilities, such as log and summary files, etc. Only Ito, Dicvol and Treor are run from
their authors' unmodified binaries (in which case the adaptations are made via a post-processor which scans their output). The
adapted versions call facilities within the main Crysfire module and cannot be run as standalones. In most cases the name of
the system version has been changed from that of the authors' base version, to emphasise that the original author is not
responsible for any problems that might arise through these modifications.
Program Version Author(s) Documentation Q2{indx}**
Ito v12 (Ito12) (1994) Jan Visser Ito12.wp1 Q2IT
Dicvol Dicvol91 (1993) Daniel Louër Dicvol91.wp1 Q2DV

& A. Boultif
Treor Treor90 (1995) Per-Eric Werner Treor90.wp1 (.doc) Q2TR

Treor90.sht
Taup v3.3a (11Jun02) Daniel Taupin: Powder (1974) Taup9606.doc Q2TP

(extended by R. Shirley)*
Kohl v7.01b (10Jul02) Franz Kohlbeck: TMO (2001) (To follow) Q2KL
(Kohl701) (extended by R. Shirley)*
Fjzn6 v6.22a (12Jun02) Jan Visser & R. Shirley (much of Ito12.wp1 applies) Q2FJ
(Fjzn622)
Lzon v6.23b (31Jul02) R. Shirley, D. Louër LzonData.doc (.txt) Q2LZ

(Lzon623) & Jan Visser
Losh v6.2b LoshFzrf (10Jul02) D. Louër & R. Shirley* LoshF62b.rtf (txt) Q2LS
(LoshFz62)
Mmap v9.45.18 (2Aug02) Robin Shirley (via online help) Q2MM

(incorporated in CFmain)
ClePage v1.5 (30Apr02) Ton Spek & A.Meetsma - -

(ClePag15) Crysfire adaptation by R.Shirley
* including FZRF cell refinement & evaluation appended from Jan Visser's ITO6
** the current versions are suffixed _01 (at 2Aug02)
After some 3 years of intensive development, Crysfire is reasonably complete, but suggestions for improvement are welcomed
and I hope other indexing programs (e.g. N-TREOR, AUTOX and SCANIX) may be added as opportunity permits, subject to
their author's permission. To be a candidate for support by Crysfire, an indexing program must be able to run in c.550KB
within an MS-DOS environment under Windows 3.x, 95, etc., (without a DOS extender), be able to use powder-line positions
(rather than require full profiles), and be sufficiently mature for Crysfire to be supplied with either a good set of default
parameter values or the rules to calculate them.
Real-mode under MS-DOS might be dismissed as a primitive environment, but it is computationally efficient and well suited to
these compact but computationally intensive programs. A protected-mode Windows version of LZON ran 3 times slower than
the otherwise-identical DOS version (in a DOS box under Windows 95). Presumably a 32-bit version would do better, but the
basic argument still applies.
A 32-bit version of Crysfire for industrial use (Industrial Crysfire) is under development (using Delphi) – this will be aimed
more at technicians and other non-crystallographers, with an emphasis on bulk processing and ease of use. In due course, some
of these developments will feed back into general Crysfire releases, just as Industrial Crysfire will benefit from its DOS
predecessors. (Plans have been dropped for a proposed more ambitious 32-bit Crysfire replacement - the "Indexer’s
WorkBench" - which was to be supported under both 32-bit Windows and Linux and developed by a distributed team working
via the Internet, since this did not succeed in attracting a critical mass of programming support. However, hope is not lost that
a 32-bit version of Crysfire will run under Linux some day, via Kylix, Borland's Delphi equivalent)
12
6.2 Associated Crysfire software
Program Version Author (and date) Description
Crysfire (for Crysfire 2002) Robin Shirley (29Jun02) Crysfire bootstrap and launch script
CFmaster (for Crysfire 2002) Robin Shirley (4Jul02) Master automatic-indexing script
CF_Home (for Crysfire 2002) Robin Shirley (17Jun02) Short script to plant home directory path
CFsetup (for Crysfire 2002) Robin Shirley (13Jun02) Short script to set up Crysfire 2002 (not for Win/XP)
CFconfrm v1.4 Robin Shirley (8Jul02) Performs initial confirmation dialogue
CFmain v9.45.18 (CFmain & Robin Shirley (2Aug02) Powder diffraction utility / indexing wizard
CFma4518.ovr)
Qdat v6.28L (Qdat628L) Robin Shirley (10Jul02) Indexing-data format translator
ITlog v2.1 (ITlog21) Robin Shirley (13Jul02) Log/summary post-processor for ITO12
DVlog v2.1 (DVlog21) Robin Shirley (4Jun02) Log/summary post-processor for DICVOL91
TRlog v2.1 (TRlog21) Robin Shirley (17May02) Log/summary post-processor for TREOR90
VRatio v1.2 Robin Shirley (16Jul99) Recalculates V/V1 fields in log/summary
QHead v1.2 Robin Shirley (29Jun99) Creates log/summary headings file
CSort (13Aug90) Open Software Movement Filter to sort files of strings
DelifNul v1.0 Robin Shirley (16May02) Deletes a specified file if empty
WhereAmI v1.0 Robin Shirley (18Jun02) Plants current directory path in the environment
Unscale v1.1 (Uscale11) Robin Shirley (13Dec00) Restores scale to summary files for rescaled data
MergeSum v1.1 Robin Shirley (3Jul02) Merges two Crysfire summary files
WF2Crys v1.7b Robin Shirley (24Jul02) Converts WinFit peaks file to Crysfire dataset
X2Crys v1.7c Robin Shirley (2Aug02) Converts XFIT peaks file to Crysfire dataset
UDI2Crys v1.30 Robin Shirley (3Jul02) Converts Philips UDI peaks file to Crysfire dataset
EVA2Crys v1 Arie van der Lee (26Apr02) Converts Bruker EVA output file to Crysfire dataset
Crys2CIF v 1.7b Robin Shirley (14Jun00) Converts Crysfire dataset to Powder CIF file
6.3. Disclaimers
With so much esoterica to sift through and intricate hierarchies of parameters to disentangle, it would be amazing if these pages
contained no errors, even if there had been time and leisure to sort it all out (which, as anyone involved in software
development will know, was far from the case). Following tradition, this manual was revised as a final task after the
completion of program development and testing. Naturally I’ve tried to make it as accurate as I could manage, but this cannot
be guaranteed. If you come across what seem to be errors, please let me know at R.Shirley@ surrey.ac.uk.
Note that Crysfire simply reports the possible solutions that the various indexing programs have found, which, even if
physically correct, will not necessarily be in their simplest or most symmetrical settings. Different indexing programs may
also have used different settings for the same solution (which will thus have related or identical V/V1 ratios). Consider
using the Laugier & Bochu Chekcell program to clarify such issues and to assign probable space groups, also available from
the CCP14 website - see the final sections of this manual.
13
6.4 Changing Directory within Crysfire
Crysfire uses two directory paths, both of which are fixed for the duration of a run:
1) Crysfire home directory (as defined by the CF_Home script)

2) Crysfire data directory (the directory in which the Crysfire run was launched)
In addition, the current directory for loading datasets and for reading and viewing files can be changed by issuing the DR
command from a Crysfire command prompt.. Note, however, that this does not change the Crysfire data directory, and that this
will be returned to automatically whenever an indexing run is launched, to ensure that the relevant summary and log files, etc.,
will be updated consistently and appropriately. To summarise, Crysfire always runs within the original data directory from
which it was launched, but by using its DR command, datasets and cells can be loaded from elsewhere.
Note that it is risky for either the Home or Data directory path to contain long directory names. This will often work under
Windows 95 or 98 (though reportedly not always under W98), it is likely to fail under Windows ME and later due to subtle
changes in the way that operating system services are delivered in those environments. For the time being, the safest
configuration generally is for both of these pathnames to contain only DOS-style 8.3 character names.
6.5 Etymological Note

Crysfire evolved in 1999 from its much more limited predecessor Crys2Run, and was renamed to emphasise the major changes
in scope and functionality. Apart from several new indexing targets, there were many new features, such as targeted Qdat files,
cumulative log and summary files for each dataset, the ability to import WinFit and XFIT peaks files, and much more. Crysfire
2000 was an enhanced release in 2000, and Crysfire 2002 is of course the present release, largely rewritten and greatly
enhanced and extended.
The name “Crysfire” reflects the multi-target approach promoted by Lachlan Cranswick in his CCP14 website tutorials (who,
as you can see, succeeded in wearing down my resistance to what I tended to see as a possible de-skilling of powder indexing).
“Crysfire” brings echoes too of “crossfire” (between the different programs), “quickfire” (how, hopefully, it will operate), and
perhaps a reference to what I felt I’d stepped into from the frying pan, while trying to get it finished in time for its original
release at the Glasgow IUCr Congress in August 1999.
14
7. Crysfire (.CDT) Dataset File Format
Ordinary Crysfire users should never need to concern themselves with the details of the .CDT dataset file format described
in this section, since all relevant operations are performed automatically by the Crysfire system. This information is
provided for programmers who may wish to support this format in their own software (as for example has been done in the
Laugier & Bochu Chekcell program).
7.1 General Properties

A Crysfire dataset file (.CDT) is composed entirely of ASCII text. Items within any line are comma delimited, with strings
in double quotes (so string items must not themselves contain any double-quote ["] characters). All lengths are in
Angstroms; all reciprocal lengths are in reciprocal Angstroms; all powder constants and related quantities are in Q-units of
10000/dsq (where dsq is in Angstroms-squared); all angles are in degrees;
The present format dates from v9.30 (May 1999), when the first 3 (starred) lines were added at the beginning of the dataset
(as described in the "Warning line"). This is now principally of historical interest, since it's doubtful whether there are any
users out there caught in a timewarp and still running a pre-1999 version.
7.2 Detailed Description

*Datestamp line (approx 60 chars: one line, version and date/timestamp)
(Note: to flag the presence of the current format, this line must start with CRYS or Crys and exceed 8 chars)
*Dataset title (up to 72 chars of description: one line, always present)
*Warning line (69 chars - To read with CRYS before v9.30, delete first 3 lines)
Dataset header (stored as 1 line, always present):

Dset = dataset name,
Nobs = Number of obs lines,
Ctype = Cell input type (0/1/2/3 = none/direct/Q/Delaunay),
Ncalc = Number of calc lines,
Qmax (for calc lines),
Gflag (1 if Hlimits stored),
W0 = wavelength (in A),
Z2Th (zero correction to be added to 2Theta values),
Dflag (0/1 = obs data given as Q/2Th),
Abs = Absences flag (Bravais)
(Iflag is not stored explicitly but inferred from whether OI(1) is non-zero in the obs pattern)
Observed pattern (stored 1 line per obs line, only present if Nobs non-zero):
For i = 1 to Nobs
OQ = Qobs,
OH,OK,OL = hkl assigned to this line (if any, otherwise zeroes),
OT = 2Theta (degrees),
OI = Intensity code / Intensity (either a qualitative code from 0 to 9, or a measured intensity)
Cell data (stored as 6-row table, only present if Ctype non-zero):

for i = 1 to 6
DD = direct cell (A, deg),
PP = Delaunay constants,
QQ = powder constants,
RR = reciprocal cell (A-1,deg),
DSC = direct sin & cos,
RSC = reciprocal sin & cos,
GL = Given Hlimits (hmin,hmax,kmin,kmax,lmin,lmax)
Calc pattern (stored 1 line per calc line, only present if Ncalc non-zero. These are provided only for reference since they are
recalculated whenever they are needed within CFmain, hence it is always harmless to set Ncalc = 0 and omit them):
for i = 1 to Ncalc
CQ = Qcalc,
CH,CK,CL = hkl
15
8.1 Copyright and Licensing
The Crysfire system is freely available for non-profit use, but it is not public domain. Copyright in all its parts is asserted by
and reserved by the relevant authors.
Thus the overall Crysfire system and user interfaces, including its scripts and its associated programs (CFmain, CFconfrm,
DelifNul, WhereAmI, Qdat, ITlog, DVlog, TRlog, VRatio, QHead, WF2Crys, XF2Crys, UDI2Crys, Crys2CIF) as listed above
(but excluding indexing programs contributed by other authors) are © R.Shirley, 2002.
Similarly, copyright (or copyleft) is reserved by the various authors of the indexing programs (including myself, where
applicable). Derivative copyright in the adaptations and extensions to the indexing programs made to support the user
interfaces within Crysfire is © R.Shirley, 2002, subject to the rights of the authors of the relevant base versions of those
programs. Licensing fees for commercial use of Crysfire cover only my user interfaces and modifications to those indexing
programs, and expressly make no charge for any contributed code, which is distributed freely in the same spirit that it was
received.
For commercial licences covering use of all user interfaces and adaptations in the Crysfire system for which I hold the
copyright (contributed code remains free of charge), and for confidential consultancy, please contact me at
R.Shirley@surrey.ac.uk. Further information is given in the associated document file Licence.txt.
8.2 Distribution and Tutorial

The Crysfire suite is distributed free for non-profit use via the CCP14 web site (http://www.ccp14.ac.uk), where detailed
tutorials have been provided by Lachlan Cranswick. It is also included in the CCP14 Xtal Nexus CD-ROM.
For commercial distribution, please contact me at R.Shirley@surrey.ac.uk.
8.3 Conditions of Use

For non-profit use, the following conditions apply:
1) This software may only be distributed on the same terms that it was received, which is freely for non-profit use.
Neither the original versions nor any derived or modified versions may be sold or incorporated in any commercially
distributed system, without the express permission in writing of the relevant copyright holders. These terms shall be
binding on all subsequent recipients.
2) Users who are employees of a commercial company may only use Crysfire under this free licence if (a) their use is
exclusively for academic or other non-profit purposes; (b) their employer makes no use of any of their results for any
purpose, including publicity; (c) Crysfire is installed and used for this purpose only on non-company computer(s).
3) If use of the Crysfire suite makes possible a published paper, then both the Crysfire suite itself and any indexing
programs that contributed materially to this result should be cited in the references section of the paper (some examples
of possible references to cite are given below).
8.4 General Limitations

Crysfire assists users to find possible solutions to the powder-indexing problem, in the form of complete or partial unit cells.
Because this is a complex problem in heuristics and induction which does not permit solutions to be identified with certainty
(until they are confirmed by structure determination), any trial cells that are reported can only be suggestions, and the final
responsibility for any decisions must lie with the user.
Although every effort has been made to ensure that the software in the Crysfire system operates correctly and in accordance
with its documentation, Crysfire is distributed strictly "as is". Responsibility for interpreting its output lies exclusively with
the user and no liability direct or indirect shall be incurred by any author or distributor for any losses that may result from its
output or any interpretation of its output. It is the position of myself and all other contributing authors that, since the output can
only contain suggestions for informed evaluation by the user, no reasonable use of the system can give rise to any liability.
It is a condition for using Crysfire that, as user, you understand and accept this situation.
16
9. References
9.1 Crysfire Suite

R. Shirley (2002), The Crysfire 2002 System for Automatic Powder Indexing: User’s Manual, The Lattice Press, 41 Guildford
Park Avenue, Guildford, Surrey GU2 7NL, England. (i.e. this manual)
9.2 Specific Indexing Programs

ITO:
Visser, J. W. (1969), A Fully Automatic Program for Finding the Unit Cell from Powder Data, J. Appl. Cryst., 2, 89-95.
DICVOL:
Boultif, A. & Louër, D. (1991), Indexing of powder diffraction patterns for low-symmetry lattices by the successive
dichotomy method, J. Appl. Cryst., 24, 987-993.
Louër, D. & Vargas, R. (1982), Indexation Automatique des Diagrammes de Poudre par Dichotomies Successives, J. Appl.
Cryst., 15, 542-545.
TREOR:
Werner, P.-E., Eriksson, L. & Westdahl, M. (1985), TREOR, a Semi-Exhaustive Trial-and-Error Powder Indexing Program for
All Symmetries, J. Appl. Cryst., 18, 367-370.
TAUP:
Taupin, D. (1973), A Powder-Diagram Automatic-Indexing Routine, J. Appl. Cryst., 6, 380-385.
(A later paper exists, but it does not refer to the base version used in the Crysfire system.)
KOHL:
Kohlbeck, F. & Hörl, E. M. (1976), Indexing Program for Powder Patterns Especially Suitable for Triclinic, Monoclinic and
Orthorhombic Lattices, J. Appl. Cryst., 9, 28-33.
Kohlbeck, F. & Hörl, E. M. (1978), Trial and error indexing program for powder patterns of monoclinic substances, J. Appl.
Cryst., 11, 60-61.
FJZN6:
Shirley, R. (2002), A modified version of Visser’s ITO zone-indexing program, using the Ishida & Watanabe PM criterion for
zone evaluation, (not yet published). See also Visser (1969) for the ITO6 base version, and Ishida & Watanabe (1982) for
the PM criterion.
LZON, LOSH:
Shirley, R. & Louër, D. (1978), New powder indexing programs for any symmetry which combine grid-search with successive
dichotomy, Acta Cryst., A34, S382.
PM Criterion (used in FJZN6 and LZON):
Ishida, T & Watanabe, Y. (1982), A criterion method for indexing unknown powder diffraction patterns, Z. Krist., 160, 19-32.
9.3 General Powder Indexing (a brief selection, concentrating on material relevant to Crysfire users)
Calvert, L. D., Flippen-Anderson, J. L., Hubbard, C. R., Johnson, Q. C., Lenhert, P. G., Nichols, M. C., Parrish, W., Smith, D.
K., Smith, G. S., Snyder, R. L. & Young, R. A. (1980), Standards for the publication of powder patterns: the American
Crystallographic Association Subcommittee's final report, in Accuracy in Powder Diffraction, ed. Block, S. & Hubbard,
C. R., NBS Spec. Publ. 567, 513-535.
Ito, T. (1949), A General Powder X-Ray Photography, Nature, 164, 755-756.
17
Ito, T. (1950), X-ray Studies on Polymorphism, Maruzen, Tokyo, 187-228.
Louër, D. (1998), Advances in powder diffraction analysis, Acta Cryst. A, 54, 922-933.
Mighell, A. D. & Santoro, A. (1975), Geometrical Ambiguities in the Indexing of Powder Patterns, J. Appl. Cryst., 8, 372-374.
Mighell, A. D. (1976), The Reduced Cell: Its Use in the Identification of Crystalline Materials, J. Appl. Cryst., 9, 491-498.
Mighell, A. D. & Stalick, J. K. (1980), The reliability of powder indexing procedures, in Accuracy in Powder Diffraction, ed.
Block, S. & Hubbard, C. R., NBS Spec. Publ. 567, 393-403.
Shirley, R. (1975), Recent advances in determining unknown unit cells from powder diffraction data, Acta Cryst., A31, S197.
Shirley, R. (1978), Indexing powder diagrams, in Crystallographic Computing, ed. Schenk, H., Olthof-Hazekamp, R., van
Koningsveld, H. & Bassi, G. C., Delft University Press, Holland, 221-234.
Shirley, R. (1980), Data accuracy for powder indexing, in Accuracy in Powder Diffraction, ed. Block, S. & Hubbard, C. R.,
NBS Spec. Publ. 567, 361-382.
Shirley, R. (1984), Measurement and Analysis of Powder Data from Single Solid Phases, in Methods and applications in
crystallographic computing, Hall, S. R. & Ashida, T., Clarendon Press, Oxford, 411-437.
Shirley, R. (2000), Progress in Automatic Powder Indexing, Proceedings of EPDIC-7, Barcelona, May 2000 (to be published).
Smith, G. S. & Snyder, R. L. (1979), FN: A Criterion for Rating Powder Diffraction Patterns and Evaluating the Reliability of
Powder-Pattern Indexing, J. Appl. Cryst., 12, 60-65.
Snyder, R. L., Johnson, A. C., Kahara, E., Smith, G. S. & Nichols, M. C. (1978), An analysis of the powder diffraction file,
Lawrence Livermore Laboratory, University of California, Report UCRL-52505.
Werner, P.-E. (1976), On the Determination of Unit-Cell Dimensions from Inaccurate Powder Diffraction Data, J. Appl.
Cryst., 9, 216-219.
Wolff, P. M. de (1963), Indexing of Powder Diffraction Patterns, Adv. X-Ray Anal., 6, 1-17.
Wolff, P. M. de (1968), A Simplified Criterion for the Reliability of a Powder Pattern Indexing, J. Appl. Cryst., 1, 108-113.
Wolff, P. M. de (1972), The definition of the indexing figure of merit M20, J. Appl. Cryst., 5, 243.
10. Technical Reference Notes on Individual Indexing Programs

The following sub-sections contain detailed technical notes on the general properties and implementation characteristics of
each of the indexing programs supported by the Crysfire INdex command.
The sequence begins with the classic trio of Ito, Dicvol and Treor, then follows the order given in the INdex command menu:
IT, DV, TR
TP, FJ, KL, LZ, MM, LS
Sub-sections:
10.1 IT = Ito (VIsser)

10.2 DV = Dicvol (Louër)
10.3 TR = Treor (Werner)
10.4 TP = Taup (Taupin: Powder)
10.5 FJ = Fjzn (Visser & Shirley)
10.6 KL = Kohl (Kohlbeck: TMO)
10.7 LZ = Lzon (Shirley, Louër & Visser)
10.8 MM = Mmap (Shirley)
10.9 LS = Losh (Louër & Shirley)
18
10.1 ITO (Jan Visser)
Deductive search in index space by zone-indexing
ITO12 performs best when given 30-40 accurately measured powder lines. It is relatively little affected by impurity lines
unless they are among the first 5 lines (hardly at all if outside the first 20). It is optimised for the lower symmetry systems from
orthorhombic downwards – consequently high-symmetry lattices may well get reported in an orthorhombic setting, perhaps
with a note that a higher symmetry setting may exist. The Bravais lattice is inferred, and Bravais lattice absences taken into
account when calculating M20. During refinements, an attempt will be made to estimate and refine the 2Theta zero correction.
(See also FJZN6 for a variant that will sometimes succeed where ITO12 fails.)
Note that ITO12 is functionally the latest version of the ITO program - although a later version ITO15 exists, it differs from
ITO12 only by providing an interactive data-file interface on PCs, which is irrelevant when ITO is run under Crysfire.
Q2IT Runs the ITO12 zone-indexing program automatically on the dataset given in targeted Qdat input file %1.QIT (written,
for example, by Crysfire), using Qdat/ITO12 defaults unless specified otherwise (or a direct indexing run [with the Crysfire DI
command] that by-passes Qdat if %2 = -Run).
Typical run times: a few seconds on a 200MHz Pentium.
usage Q2IT {datafile} {run_flag}
where {datafile} is the base name of the %1.QIT targeted Qdat input file
(i.e. without its .QIT extension)
{run_flag} is the optional flag "-Run" which, if present, indicates that

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .ITD)
The same {datafile} name is used automatically when naming all subsequent files in the run:
Qdat targeted input file = {datafile}.QIT

Qdat output listing file = {datafile}.QDO
ITO12 input data file = {datafile}.ITD

ITO12 main output file = {datafile}.ITO
ITO12 short output file = {datafile}.ITS
ITO12 input verification = {datafile}.ITV
ITO12 solutions-log = {datafile}.ITG
ITO12 solutions-summary = {datafile}.ITM
The solutions log and summary are also appended to the log and summary files for the specified dataset: {datafile}.LOG and
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and Merit (the ITlog post-
processor does not use any acceptance criteria of its own based on I20 or M20, but simply reports the “4 most probable
solutions” that are listed in the ITO12 output files).
As usual, at the end of the indexing run, first the short output file, and then the sorted solutions summary, are displayed
using the editor specified in environmental variable INDEXEDIT (default: WordPad under Win9x, etc. or Edit under
DOS). Thus the following files provide a record of all runs for the specified dataset, after updating with the current run as
described above:
Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)
Dataset solutions-summary = {datafile}.SMH (sorted and with headings)
Le Page reduced-cell analysis = {datafile}.CLO (in sorted order)
Le Page reduced-cell summary = {datafile}.CLM (headed summary)
Old dataset solutions-log = {datafile}.LGK (backup)

Old dataset solutions-summary = {datafile}.SUM (backup)
Old Le Page analysis = {datafile}.COK (backup)
Old Le Page summary = {datafile}.CMK (backup)
[Because of the close similarity between their data formats, LZON will usually accept data files originally targeted for ITO12,
either as an unchanged .QDT file, or by renaming the extension of a .ITD file to .LZD (but not those for FJZN6, since they lack
the second parameter line)]
19
10.2 DICVOL (Daniel Louër)
Exhaustive search in parameter space by successive dichotomy
DICVOL91 uses the optimal exhaustive algorithm in parameter space (a form of binary search), at least down to monoclinic,
though this impacts on its speed below orthorhombic. Where it searches exhaustively (i.e. down to monoclinic), DICVOL91
can demonstrate the non-existence as well as the existence of solutions in particular crystal systems, and is well suited for
searches of the higher symmetry crystal systems down to orthorhombic, and also (but slower) to monoclinic. It usually
performs best with around 20 well-measured lines, which must be from a single solid phase since it does not tolerate impurity
lines.
DICVOL91 searches outwards in 400A3 shells of increasing cell volume, which means that low-volume solutions are found
quickly but searches to high volumes in low symmetry may become very lengthy.
Although an explicit hexagonal search is made, any hexagonal solution will usually be picked up in its equivalent V/2
orthorhombic setting during the preceding volume shell, upon which the search terminates and the hexagonal setting never gets
reported. Because of this, it is now recommended that DICVOL is run in two separate passes, firstly to screen for high
symmetry crystal systems down to tetragonal, and then separately for lower symmetry solutions in orthorhombic and
monoclinic. Crysfire 2002 provides specific options for this (as for triclinic searches, but see the warning below)
The original Crysfire 2000 default of a single search down to monoclinic is still available as option 0 (but no longer the
default). If this is selected, and an orthorhombic solution is reported but a hexagonal one suspected, that hypothesis can be
tested by making a further run, setting DICVOL91’s VOLMIN parameter in line 3 to the upper bound of the volume shell in
which the orthorhombic cell was reported. This forces the next shell to be searched, and hence any hexagonal solution within it
to be reported. However, it is easier to make separate high- and low-symmetry runs as suggested.
In general, users should be aware of the fact that, to reduce run times, in each of its search phases DICVOL91 is liable to
terminate its searches at the end of the first volume shell that contains a possible solution, without exploring further volume
shells, nor perhaps lower-symmetry crystal systems. Since a better solution may exist at higher volume or lower symmetry, it
may be prudent to consider a rerun using parameters such as VOLMIN to force a search of additional volume shells and/or
crystal systems.
A premature termination is more likely if large 2Theta limits have been supplied, which will also increase run times – bear in
mind that DICVOL91 will itself increase the supplied limits by an additional margin of 0.015 degrees (see notes on defaults
below).
Features such as these mean that, at least for low-symmetry work, DICVOL91 has been optimised more for manual guidance
by experienced users than for fully automatic use by non-specialists.
Q2DV Runs the DICVOL91 indexing program automatically on the dataset given in targeted Qdat input file %1.QDV
(written, for example, by Crysfire), using Qdat/DICVOL91 defaults unless specified otherwise (or a direct indexing run [with
the Crysfire DI command] that by-passes Qdat if %2 = -Run).
Typical run times on a 200MHz Pentium: a few seconds down to orthorhombic, 2-30 minutes for a monoclinic search, and
from a few minutes to many hours to finish in triclinic, depending very much on cell volume
Defaults Crystal systems: down to triclinic. VOLMAX: 6000 BEMAX: 130 degrees
EPS (±2Theta limits on observed lines): 0.03 deg. (Crysfire, Qdat, DICVOL91 - i.e. all identical)
(Default 2Theta limits take precedence in the order Crysfire > Qdat > DICVOL91. Before starting its searches,
DICVOL91 will add a further margin of 0.015 to the 2Theta limits in EPS, thus increasing the effective default
to 0.045 degrees.)
To change these, edit {datafile}.DVD and use it directly.
By default, Crysfire will configure DICVOL to scan all higher-symmetry crystal systems automatically from cubic down to
monoclinic. It can also optionally scan for triclinic solutions, but this can take more than an hour and, if interrupted with
Ctrl-Break, the latest output buffer will not be saved to disk. Note that triclinic searches within DICVOL are not
exhaustive, so do not assume that if it fails to find a solution within triclinic, none exist within the region it has searched.
Although triclinic DICVOL searches are not exhaustive, they can still become very time-consuming (unless guided with
manual intervention by an experienced user, preferably with very accurate data). Thus it's usually more effective to seek
triclinic solutions with ITO12, TREOR90, KOHL, FJZN6 and LZON before running a triclinic scan with DICVOL.
CFmain (from v9.29) in Crysfire can set the DICVOL parameter concerned (JTR = parameter 8, line 2 in the .DVD datafile:
0/1 for skip/include a triclinic scan).
20
If DICVOL needs to be interrupted with Ctrl-Break (or Ctrl-C), it’s important to reply N to the question “Terminate batch
job (Y/N)”, so as to be shown the contents of the short output file, as far as it has been written (usually not the last buffer-
full, as noted above) and to proceed to the log/summary processing.
usage Q2DV {datafile} {run_flag}
where {datafile} is the base name of the %1.QDV targeted Qdat input file
(i.e. without its .QDV extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .DVD)
Qdat targeted input file = {datafile}.QDV

DICVOL91 input data file = {datafile}.DVD

DICVOL91 output file = {datafile}.DVO
DICVOL91 solutions-log = {datafile}.DVG
DICVOL91 solutions-summary = {datafile}.DVM
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and Merit (the DVlog post-
processor does not impose any acceptance criteria of its own based on I20 or M20, but accepts all solutions that have been
listed in the DICVOL91 output files).
described above:


21
10.3 TREOR (Per-Eric Werner)
Semi-exhaustive, heuristic search methods in index space
TREOR90 performs fast and efficient searches down to triclinic symmetry. It prefers high standards of data measurement, but
is rather more forgiving over impurity lines. About 25 well-measured observed lines are recommended. A very thorough
manual is provided, with many examples.
Q2TR Runs the TREOR90 indexing program automatically on the dataset given in targeted Qdat input file %1.QTR (written,
for example, by Crysfire), using Qdat/TREOR90 defaults unless specified otherwise (or a direct indexing run [with the Crysfire
DI command] that by-passes Qdat if %2 = -Run).
Typical run time on a 200MHz Pentium: under a minute.
Defaults VOL: 6000 MERIT: 9 (i.e. halt on finding a solution with M20>9)
To change these, edit {datafile}.TRD and use it directly.
usage Q2TR {datafile} {run_flag}
where {datafile} is the base name of the %1.QTR targeted Qdat input file
(i.e. without its .QTR extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .TRD)
Qdat targeted input file = {datafile}.QTR

TREOR90 input data file = {datafile}.TRD
TREOR90 main output file = {datafile}.TRO
TREOR90 short output file = {datafile}.TRS
TREOR90 solutions-log = {datafile}.TRG
TREOR90 solutions-summary = {datafile}.TRM
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and Merit (the TRlog post-
processor does not impose any acceptance criteria of its own based on I20 or M20, but accepts all solutions that have been
listed in the TREOR90 output files).
described above:


22
10.4 TAUP (Daniel Taupin)
Exhaustive, index-permutation search in index space
Like DICVOL, Taupin’s program uses an exhaustive approach and so can show that solutions do not exist within particular
systems. The downside to this is that its searches become dramatically longer as the symmetry decreases, so that searches
below orthorhombic can be impractical. It is, however, useful for screening for high symmetry solutions, since searches down
to orthorhombic are quite fast. By default it does not allow for impurity lines, though this can be changed using its NBMAX
(NSPURI) parameter (see below).
Although the manual claims that TAUP can accept data in the form of 2Theta angles, in practice this is unsafe due to bugs in its
scheme for allowing a distinct wavelength to be specified for any line. Thus only the d-spacings option should be used (as is
the case when TAUP is called within Crysfire).
TAUP originally used its own figure of merit, based on squares of differences. This original line-by-line version is still output
but now labelled “T-Merit”. A conventional M20 value is now also reported for each proposed solution. The acceptance test
for reporting solutions is still based on a minimum level of T-Merit - by default 5, though this can be changed in the TAUP
data file, using line 2 parameter 7 (FWMINI).
Q2TP Runs Taupin’s index-permutation program automatically on the dataset given in targeted Qdat input file %1.QTP
(written, for example, by Crysfire), using Qdat/TAUP defaults unless specified otherwise (or a direct indexing run [with the
Crysfire DI command] that by-passes Qdat if %2 = -Run).
Typically this takes 10-20 seconds down to orthorhombic on a 200MHz Pentium, over an hour down to monoclinic, and
forever (?days, ?weeks) down to triclinic.
Thus, being exhaustive, TAUP is very useful down to orthorhombic, but in general it is much more efficient to try other
programs such as ITO12, TREOR90, KOHL, FJZN6 and LZON before considering low-symmetry searches with TAUP. By
default under Crysfire, TAUP halts after orthorhombic. Low-symmetry searches can be interrupted with Ctrl-Break, but, as
with DICVOL, the last output buffer will then not be saved.
If TAUP needs to be interrupted with Ctrl-Break (or Ctrl-C), it’s important to reply N to the question “Terminate batch job
(Y/N)”, so as to be shown the contents of the short output file, as far as it has been written (usually not the last buffer-full, as
noted above) and to proceed to the log/summary processing.
Defaults Flags: DFG CTHO (i.e. d-spacings, brief output, crystal systems down to orthorhombic)
VOL: 6000 T-MERIT: 5 (as defined by TAUP – see above - perhaps equivalent to M20 = 7)
NSPURI=0 (2nd parameter on line 2 - can be edited then re-run directly)
±2Theta limits: 0.04 degrees (converted by Qdat to d-spacing limits for TAUP)
To change these, edit the Qdat input file, or edit {datafile}.TPD and use it directly.
usage Q2TP {datafile} {run_flag}
where {datafile} is the base name of the %1.QTP targeted Qdat input file
(i.e. without its .QTP extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .TPD)
Qdat targeted input file = {datafile}.QTP

TAUP input data file = {datafile}.TPD

TAUP main output file = {datafile}.TPO
TAUP cells output file = {datafile}.TPC (=TAUP.CEL cells list)
TAUP input verification = {datafile}.TPV (=TAUP.$$$ input copy)
TAUP run-restart file = {datafile}.TPR (=TAUP.RST restart unit)
TAUP least-squares file = {datafile}.TPL (=TAUP.APL for Appleman program)
(Obtained only if L flag set)
TAUP solutions-log = {datafile}.TPG
TAUP solutions-summary = {datafile}.TPM
23
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and M20. All solutions listed in
the main TAUP output file are included.
described above:


24
10.5 FJZN6 (Jan Visser & Robin Shirley)
Deductive search in index space by zone indexing,
(using Ishida & Watanabe’s PM criterion for zone evaluation)
This is a modified variant of Visser’s ITO program, resembling ITO12 but based on the earlier v6 version. Because of this, its
lacks some of the finesse of ITO12, but its strength is that it replaces the weakest aspect of ITO – the CRITER criterion used in
the zone-evaluation stage – with the more robust PM criterion of Ishida & Watanabe (1982). This means that is less likely to
discard correct zones because they finish too far down the rank order, and so it may well succeed in flushing out a solution
where ITO12 fails (however, through the workings of chance, the converse can also be true - it is worth trying both programs).
Like ITO12, it performs best when given 30-40 accurately measured powder lines, and is relatively little affected by impurity
lines unless they are among the first 5 lines (hardly at all if outside the first 20). It is optimised for the lower symmetry systems
from orthorhombic downwards – hence high-symmetry lattices may well get reported in an orthorhombic setting, perhaps with
a note that a higher symmetry setting may exist. The Bravais lattice is inferred, and Bravais lattice absences taken into account
when calculating M20. No attempt is made to estimate or refine the 2Theta zero correction (unlike with ITO12).
(See ITO12 for a later, improved version of the ITO6 base program).
Q2FJ Runs the modified FJZN6 version of Visser’s ITO6 zone-indexing program automatically on the dataset given in
targeted Qdat input file %1.QFJ (written, for example, by Crysfire), using Qdat/FJZN6 defaults unless specified otherwise (or a
direct indexing run [with the Crysfire DI command] that by-passes Qdat if %2 = -Run).
Typically this takes a few seconds on a 200MHz Pentium. Note that the main output file can be relatively large.
Defaults Tries combinations of the first 6 zones with the first 6 (NZ1 & NZ2)
Acceptance criterion TOLG for lattice refinement = 3
Solutions logged if I20>16 and M20>7
To change these, edit the Qdat input file, or edit {datafile}.FJD and use it directly.
usage Q2FJ {datafile} {run_flag}
where {datafile} is the base name of the %1.QFJ targeted Qdat input file
(i.e. without its .QFJ extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .FJD)
Qdat targeted input file = {datafile}.QFJ

FJZN6 main output file = {datafile}.FJO

FJZN6 short output file = {datafile}.FJS
FJZN6 input verification = {datafile}.FJV
FJZN6 solutions-log = {datafile}.FJG
FJZN6 solutions-summary = {datafile}.FJM
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and M20. Solutions with I20>16
and M20>7 after refinement are included.
described above:

25
26
10.6 KOHL (Franz Kohlbeck)
Heuristic search in index space
KOHL is based on Kohlbeck’s 1975 TMO program, altered and adapted for PC use and with an FZRF refinement and
evaluation stage appended (adapted from Visser’s ITO6). KOHL works rapidly and efficiently in index space, carrying out
orthorhombic, monoclinic and triclinic searches in broadly independent stages.
This independence is important, since there is a deeply obscure but catastrophic bug embedded in KOHL that consistently
affects particular datasets and can cause the run to become corrupted and abort with a floating-point error. But because the
stages are independent, this can partly be worked around. Thus if, for example, this were to affect the orthorhombic stage, it
could be worked around by rerunning with that stage deselected (the option to select and deselect individual stages is now fully
supported by Crysfire). This bug seems more likely to be triggered if unindexed lines are permitted using the LUFM
(NSPURI) parameter (see below).
Another situation in which it may be necessary to specify a particular crystal system is when solutions are found within
monoclinic, in which case KOHL will not proceed automatically to triclinic, although this has been requested. Since triclinic
KOHL searches are not particularly slow on a modern PC (typically under 5 minutes), it can be useful to rerun and force a
triclinic search.
KOHL does not make any special provision for detecting higher-symmetry solutions, so these will be reported in orthorhombic
or monoclinic settings. The FZRF postscript brings additional cell refinement, the detection of a probable Bravais lattice, level-
by-level listings and other niceties, including an alert when a higher symmetry is suspected.
KOHL is particularly useful because (when it works) it is fast, searches down to triclinic and is relatively tolerant of both
random errors and impurity lines. 2Theta error bounds are not required – by default KOHL uses a 1% error tolerance dQ/Q
(i.e. FEHL=0.01) for its primary searches. This wide tolerance contributes to its valuable lack of sensitivity to random errors,
without greatly increasing run times. The LUFM (NSPURI) parameter allows a specified number of definitely unindexed lines
to be disregarded in KOHL’s primary searches in index space (more marginally unindexed lines are already allowed for when
all the primary-search solutions are refined and reported by FZRF). Be aware, though, that the use of LUFM (NSPURI) can
trigger KOHL’s floating-point error bug in datasets and crystal systems that previously escaped it.
Q2KL Runs Kohlbeck’s index-space program automatically on the dataset given in targeted Qdat input file %1.QKL (written,
for example, by Crysfire), using Qdat/KOHL defaults unless specified otherwise (or a direct indexing run [with the Crysfire DI
command] that by-passes Qdat if %2 = -Run).
Typically this takes under a minute on a 200MHz Pentium.
KOHL is fast and effective, but, as discussed above, it can halt on a floating-point error with some datasets, especially in the
first search down to orthorhombic and if LUFM (NSPURI) is used. Happily the different searches are independent, so that a
further run that avoids the offending search may well proceed correctly.
Defaults All searches enabled (orthorhombic, monoclinic and triclinic)
usage Q2KL {datafile} {run_flag}
where {datafile} is the base name of the %1.QKL targeted Qdat input file
(i.e. without its .QKL extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .KLD)
Qdat targeted input file = {datafile}.QKL

KOHL input data file = {datafile}.KLD

KOHL main output file = {datafile}.KLO
KOHL short output file = {datafile}.KLS
KOHL input verification = {datafile}.KLV
KOHL solutions-log = {datafile}.KLG
KOHL solutions-summary = {datafile}.KLM
27
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and M20. Refined solutions with
I20>15 and M20>9 are reported at the FZRF stage (solutions with M20>7 having been passed on to FZRF from the primary
search).
described above:


28
10.7 LZON (Robin Shirley, Daniel Louër & Jan Visser)
Combination strategy: ITO-style zone-search for Q(A,B,F),
Shirley heuristic for Q(C), exhaustive search in parameter space
by successive dichotomy for Q(D,E))
LZON uses a semi-exhaustive strategy, in that it makes some explicit and hopefully judicious assumptions to restrict the search
volume in solution space, then makes an exhaustive search of the chosen regions. This means that it can rule out the possibility
of a solution existing within the regions that it has searched, as defined by the parameters used. Another feature of LZON
(from v6.23b) is that it writes a basis-set list (BSL) file for use by MMAP's indexing mode.
LZON's particular strength shows in the multi-solution dominant-zone cases that are often pathological for other programs.
Because its heuristics are based on the most dominant zones present, it is actually at its strongest in these cases. Also, though
using a zone-indexing framework, it takes a different approach to lattice-building and only needs to discover a single correct
zone (the most dominant one present and hence the easiest to find), where pure zone-indexing programs like ITO12 and FJZN6
need to find two.
Being semi-exhaustive rather than deductive, however, it is not as fast as ITO12 or FJZN6, taking up to 15 minutes where they
take only a few seconds. Any impurity lines must be allowed for explicitly using its NSPURI parameter (default: none), which
can lengthen search times considerably if non-zero. This also affects TOLG – the acceptance limit for indexed lines during
lattice refinement. If NSPURI=0, a broader default limit of TOLG = 6 QU. is used, reducing to 3 if impurity lines are
expected. TOLG influences the radius of convergence of refinements, which may fail to lock on to the best fit if TOLG
excludes too many lines in the early stages, so TOLG should not be based only on the expected data accuracy.
Both Ishida & Watanabe’s PM and the original Visser CRITER are available as criteria for zone evaluation (default: I&W PM
- see FJZN6).
Q2LZ Runs the LZON indexing program automatically on the dataset given in targeted Qdat input file %1.QLZ (written, for
example, by Crysfire) or a direct indexing run [with the Crysfire DI command] that by-passes Qdat if %2 = -Run, using
Qdat/LZON defaults unless specified otherwise (effectively the same format as for ITO12).
Typical run times on a 200MHz Pentium: 2 to 15 minutes. Note that the main output file can be relatively large.
Defaults NZ1: 8 (use top 8 zones as basis zones) [Crysfire default = 8, max 20]*
NZ2: 0 (don't rerun any basis zones with basis line as 002 [unless the zone is
rectangular or centred])
WAVEL: 1.5406 (CuKα1 wavelength in Angstroms)*
D2THDF: ±2Theta limits on observed lines: 0.04 deg.(Crysfire), 0.03 (Qdat), 0.06 (LZON)
(Default 2Theta limits take precedence in the order Crysfire > Qdat > LZON)*
ALPMIN: 30 (minimum alpha* in degrees)
BETMIN: 30 (minimum beta* in degrees)
ICRIT: 0 (zone evaluation by Ishida & Watanabe’s PM)*
VOLMAX: 1500+ (estimated automatically from the first 3 observed lines)
FOMMIN: 7 (minimum figure of merit for a refined solution to be accepted)
NSPURI: 0 (i.e. no unindexed lines permitted) [Crysfire default = 0, max 5]*
TOLG: 6 if NSPURI=0, else 3 (acceptance limit in QU for lattice refinement)
NRLOSH: 20 (use only the first NRLOSH lines in dichotomy searches - all lines are used for
zone-finding and for refining and evaluating the solutions)
Parameters marked with an asterisk can be changed from the Crysfire interface. To change the others, edit
{datafile}.QDT (see LZONDATA.DOC for details of LZON's data formats).
usage Q2LZ {datafile} {run_flag}
where {datafile} is the base name of the %1.QLZ targeted Qdat input file
(i.e. without its .QLZ extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .LZD)
Qdat targeted input file = {datafile}.QLZ

29
LZON input data file = {datafile}.LZD
LZON main output file = {datafile}.LZO
LZON short output file = {datafile}.LZS
LZON input verification = {datafile}.LZV
LZON solutions-log = {datafile}.LZG
LZON solutions-summary = {datafile}.LZM
LZON623 basis-set list = {datafile}.LZB
described above:


[Because of the close similarity between their data formats, LZON will usually accept data files originally targeted for ITO12,
by renaming the extension of a .QIT file to .QLZ, or that of an .ITD file to .LZD (but not those for FJZN6, since they lack the
second parameter line)]
30
10.8 MMAP (Robin Shirley)
Exhaustive search of alpha* & beta* in parameter space
by step-search across the figure-of-merit surface, for specified basis sets
In general principle, MMAP performs a similar task to LOSH (LOSHFZRF), in that it carries out a semi-exhaustive, heuristic
search, scanning exhaustively through a selected region of solution space - a single specified plane in solution space, located by
applying the Shirley-Ishida-Watanabe (SIW) dominant-zone heuristic. This is its action when called in indexing mode, which
is the default when MMAP is run via Crysfire's IN command.
The plane that is to be searched must be specified by the user, in the form of a “basis set”. This consists of a single powder
zone – the “basis zone” – specified as Q(A), Q(B) and Q(F), plus the first well-measured line not indexed by the zone, which
by the SIW heuristic is taken as Q(C). The resulting four powder constants Q(A,B,C,F) form the basis set for the search, which
now only need cover the 2-dimensional plane in solution space defined by Q(D) and Q(E) – i.e. alpha* and beta*. Because
step-search is inherently a much slower method than successive dichotomy (binary search), MMAP can be expected to take at
least ten times longer than LOSH to complete its search. This will still be acceptably fast (around 1 - 10 minutes on a 200MHz
Pentium, depending on cell volume and the number of observed lines used) and has the advantage of being unaffected by
NSPURI - the number of impurity lines permitted (which can greatly slow LOSH).
As for LOSH, the process of selecting a suitable basis set can most easily be understood by studying the main output file from
LZON, where it is set out for each of the basis sets used. LZON (from v6.23b) writes a basis-set list (BSL) file
({dataset}.LZB) in the data directory, so that if it is run before MMAP, this file will be picked up automatically by MMAP's
indexing mode and its basis sets (ordered on how successful they were for LZON) offered to the user. Alternatively, more
experienced users can obtain a basis zone for MMAP by examining the detailed zone-listings in the main output files of ITO12,
FJZN6 or LZON, seeking a promising prospect that was missed by the original program. This will typically be a zone with
relatively large reciprocal area (hence small direct-cell constants) and large coverage (i.e. few unobserved lines within the zone
– coverage near the origin is more significant than at higher angles). It helps to have experience and training when spotting
good powder zones, but the judicious human selector can often succeed where the zone-evaluating program failed.
As with LOSH, all solutions are treated intrinsically as triclinic, although they will be reported as monoclinic or orthorhombic
cells if they prove to lie on the corresponding symmetry lines in the figure-of-merit surface. However, unlike the post-
normalisation applied by LOSHFZRF, MMAP will leave them in their original setting.
It is recommended to use the first 20 well-measured lines, but MMAP will accept far fewer lines, even less than 10 (although
the results in such cases are likely to be disappointing).
Q2MM Since MMAP is run as an incorporated program by CFmain, this script is only required for managing the assembly
and display of summary files, etc., and running the ClePage program. It has no standalone role.
Like LOSH, MMAP can’t be run fully automatically since its purpose is to search particular user-specified basis sets – i.e. sets
of Q(A), Q(B), Q(C) & Q(F). The processes for finding basis sets and basis zones using LZON and ITO12/FJZN6 output have
been outlined above.
One can also submit trial cells that have been obtained from Crysfire or Chekcell summary files via Crysfire's LC command,
and select one of their basal zones as the basis for the search. This is also the principal route for investigating solutions in
MMAP's topographical mode, which is the default when MMAP is called directly via Crysfire's MM command.
usage Q2MM {datafile}
where {datafile} is the base name of the %1.QMM targeted LOSHFZRF input file (i.e. without its .QLS
extension)
(Q2MM does not have a {run_flag} option - since MMap is an embedded Crysfire function, the concept of a
direct-indexing run is not applicable).
Qdat targeted input file = {datafile}.QMM

MMAP map file = {datafile}.MMP (comma-delimited, optional)

MMAP solutions-log = {datafile}.MMG
MMAP solutions-summary = {datafile}.MMM
31
{datafile}.SUM respectively. {datafile}.SUM is then sorted into descending order of I20 and M20. Criteria for inclusion of
solutions from MMap are typically I20 above 15 and Merit above 5.
described above:


32
10.9 LOSH (Daniel Louër & Robin Shirley)
Exhaustive search of alpha* & beta* in parameter space
by successive dichotomy, for specified basis sets
More accurately, the system version is LOSHFZRF. LOSH is the original user-directed program for which LZON is the
automated version. “FZRF” indicates that, as with KOHL, an FZRF refinement and evaluation stage has been appended
(adapted from Visser’s ITO6).
Like LZON, LOSHFZRF is semi-exhaustive, searching exhaustively through a selected region of solution space. However,
LOSHFZRF searches only a single specified plane in solution space where by default LZON searches eight.
The plane that is to be searched must be specified by the user, in the form of a “basis set”. This consists of a single powder
zone – the “basis zone” – specified as Q(A), Q(B) and Q(F), plus the first well-measured line not indexed by the zone, which
by the Shirley/Ishida&Watanabe heuristic is taken as Q(C). The resulting four powder constants Q(A,B,C,F) form the basis set
for the search, which now only need cover the 2-dimensional plane in solution space defined by Q(D) and Q(E) – i.e. alpha*
and beta*. Such a 2-dimensional search is very fast – typically under a minute for the default settings with NSPURI=0 (no
impurity lines expected).
The easiest way to choose a basis set is by examining those listed in LZON's BSL file, which is displayed when running
MMAP in indexing mode (see the MMAP notes in section 10.8 for a fuller discussion). The process by which this is obtained
can most easily be understood by studying the main output file from LZON, where it is set out for each of the basis sets used.
A basis zone for LOSHFZRF will usually be obtained by examining the detailed zone-listings in the main output files of
ITO12, FJZN6 or LZON, seeking a promising prospect that was missed by the original program. This will typically be a zone
with relatively large reciprocal area (hence small direct-cell constants) and large coverage (i.e. few unobserved lines within the
zone – coverage near the origin is more significant than at higher angles). It helps to have experience and training when
spotting good powder zones, but the judicious human selector can often succeed where the zone-evaluating program failed.
As with LZON, all solutions begin as triclinic and are only examined and renormalised for higher symmetry by the evaluative
FZRF postscript, which also refines the cell and infers its Bravais lattice type. Solutions are accepted for logging if I20>15 and
M20>7.
It is recommended to use the first 20 well-measured lines, but LOSHFZRF is prepared to search with less, although the FZRF
stage may not like this and in such cases it may be necessary to renormalise and evaluate the solutions by hand (with the aid of
Crysfire).
Q2LS Runs the LOSHFZRF indexing program automatically on dataset given in targeted Qdat input file %1.QLS, including
a specified basis set but using Qdat/LOSHFZRF defaults unless specified otherwise (or a direct indexing run [with the Crysfire
DI command] that by-passes Qdat if %2 = -Run). Typical run times: a few seconds to c.2 minutes on a 200MHz Pentium
(depending on the dominance of the basis zone that was used, etc.).
LOSHFZRF can’t be run fully automatically since its purpose is to search particular user-specified basis sets – i.e. sets of Q(A),
Q(B), Q(C) & Q(F). Those not experienced in doing this are recommended to use LZON instead, which automates the entire
process, though at the expense of considerably longer run times while it kisses a lot of frogs so as to have a better chance of
finding a prince. LOSHFZRF is considerably more efficient, for those who know how to use it. For additional educational
value, parts of its output remain in the original French (their meaning will hopefully still be obvious).
Defaults NSPURI: 0 (i.e. no unindexed lines permitted) [Crysfire default =0, max 5]*
ALPMIN,BETMIN: 30 (minimum alpha* & beta* in degrees)
D2THDF (±2Theta limits on observed lines, for CuKα1 radiation), defaults differ as follows:
0.06 deg. (Crysfire)*, 0.03 (Q2LS, Qdat), 0.04 (LOSHFZRF),
applied in the order of precedence Crysfire > Qdat > LOSHFZRF.
LRECTAN 0 (i.e. don't force near-90deg angles to 90deg [1=do])*
FMINEQ 0.8 QU. (Crysfire)*, internal estimate (LOSHFZRF) (used in testing for equality)
Parameters marked with an asterisk can be changed from the Crysfire interface. To change the others (i.e.
ALPMIN, BETMIN) , edit {datafile}.LSD and use it directly. For more details, see LOSHF61B.rtf.
33
Datafile format for Q2LS (i.e. A datafile for Qdat, with LOSHFZRF as target – this will be generated automatically by
CFmain (v9.29+) in Crysfire, via SA and Q, with LS = LOSHFZRF specified as target)
1) Title line (20A4): Up to 80 cols of title text (no defaults)

2) Qdat parameters line (2I1,I2,6I1,5F10.0,F5.0,F10.0, 2I1,A3):
e.g. cols 1-30 as in the example below for: 2Theta data with no unindexed lines permitted
(i.e. NSPURI=0 in cols 3-4), D2TH=0.05 (cols 11-20) and wavelength 1.5406 (cols 21-30)
10 0090000 0.05 1.5406
3) Basis-set line (4F10.5): Q(A), Q(B), Q(C) & Q(F) - copied verbatim, no defaults
4) Continuation flag: A line with CONT in cols 1-4
5) Set of Nobs line-position records (e.g. obs 2Thetas: 1 per line, as F10.0)
6) End flag:A line with blanks or zero(s) in cols 1-10
usage Q2LS {datafile} {run_flag}
where {datafile} is the base name of the %1.QLS targeted LOSHFZRF input file
(i.e. without its .QLS extension)

this is to be a direct run, by-passing QDAT (in which case the {datafile} extension will be .LSD)
Qdat targeted input file = {datafile}.QLS

LOSHFZRF input data file = {datafile}.LSD

LOSHFZRF output file = {datafile}.LSO
LOSHFZRF solutions-log = {datafile}.LSG
LOSHFZRF solutions-summary = {datafile}.LSM
described above:


Defaults for direct runs:
NSPURI (line 2, cols 7-9): 0 (i.e. no unindexed lines permitted)

LRECTAN (line 2, cols 10-12): 0 (i.e. don’t set angles near 90 to 90 degrees)
FMINEQ (line 2, cols 13-17): internal estimate (for testing equality between powder constants). (The Crysfire
default is 0.8 QU. It may be helpful to reduce this for large-volume cells.)
ALPMIN,BETMIN (line 3, cols 1-14: 2F7.2): (min alpha*, beta* degrees, no defaults)
D2THDF: 0.04 degrees (used to calculate EPSIL(I) uncertainty if not specified explicitly for each line: ±2Theta
limits on obs lines, for CuKα1 radiation, 1.54056A)
34
11. Using the Chekcell Helper Program with Crysfire 2002
11.1 What is Chekcell and what does it do?

Chekcell is what Lachlan Cranswick (the CCP14 webmaster) calls an "indexing helper program". It is also more of a
toolkit, in the sense that it provides a considerable variety of facilities that can be very useful for characterising and
extending knowledge about indexing solutions, for those who know how to use them, without providing clear wizard-
directed pathways in the way that, for example, the Crysfire IN command does.
Chekcell is not itself an indexing program, relying largely on Crysfire to provide lists of trial solutions via its indexing
summary files. For its part, Crysfire does not attempt to carry out the detailed processes that are required for the further
assessment of the solutions it has found, nor pretend to know much about spacegroups, except that many of the indexing
programs make some provision for assigning Bravais lattice types (i.e. all except Dicvol, which doesn't, and Mmap which
can't).
Thus a very helpful, informal partnership and synergy has grown up between Crysfire and Chekcell, in which Crysfire
carries out the often heavy indexing computations that are involved in the first stage of the cell discovery and
characterisation process, then hands over to the graphical tools in Chekcell for the further evaluation and extension of the
trial solutions.
Unlike Crysfire, Chekcell will only run under 32-bit Windows (there is also a Linux version).
Another important difference is that, for important gains in computation speed, Crysfire works exclusively with powder-
line (i.e. diffraction-peak) positions, and has no facilities for using or displaying the raw diffraction profile.
By contrast, Chekcell makes a point of graphically integrating both the profile and the assigned line positions, for both the
observed and the calculated powder patterns. This permits the user's human skill in visual pattern-recognition and
judgement to be brought into play.
Again, though both Crysfire and Chekcell make use of Le Page reduced-cell calculations, they do so in different ways.
Crysfire carries out a bulk reduced-cell calculation on the entire list of trial solutions in its summary file, while Chekcell
can perform fuller and more detailed sub-cell and super-cell calculations, but only on a single selected trial solution at a
time.
Because of the flexibility with which the Chekcell's tools can be deployed, it is not feasible to attempt any comprehensive
account here – for a broader perspective, see the Chekcell tutorials that Lachlan Cranswick has mounted on the CCP14
website. Instead, we shall look at a single representative case study.
11.2 Using Chekcell

To make best use of Chekcell, one needs three initial types of data: a diffraction profile (in a .cpi or .raw file), a peaks list
(in one of a number of supported formats, such as Xfit), and a list of one or more trial solutions for those data (typically as
a Crysfire .sum file):
1) Launch Chekcell within the data directory for the problem in question – usually the one in which Crysfire has just
been working.
2) a) Load the profile data via File | Open | Diffraction Data File | e.g. CPI Format (*.cpi), then select the relevant profile
file (there is also a shortcut icon for this in the lower toolbar).
b) The profile window will then open, showing the observed profile of step-counts.
c) This can be zoomed simply by left-clicking on a point in the profile display and drawing out the resulting rectangle
to enclose the region to be enlarged. When the left mouse button is released, that rectangle will be zoomed up to fill
the whole profile window. Un-zoom to the original scale by clicking on the Z- button in the lower toolbar.
3) a) Similarly load the peaks list via File | Open | Peaks File | e.g. XFIT Format (*.txt), then select the relevant peaks
file (again there is a shortcut, via the Measured reflections tab and the File button).
b) You will then be asked to re-specify the wavelength, if, as in this case, it is not stored explicitly in the peaks file.
Select Other, then type in the wavelength that is already displayed in the top-left window. In the case of Cu radiation,
don't select "Cu" unless you actually want the alpha1/2 weighted mean of 1.54180, which is what "Cu" will provide.
c) A scrollable window containing the list of observed line (peak) positions will then appear, and simultaneously these
positions will be marked as black vertical lines in the profile window, above the profile baseline.
35
4) a) Load the cells list via File | Open | Cell File | e.g. Crysfire Summary file, then select the relevant file (again a
shortcut is provided, via the Cell parameters tab and the blue Crysfire file button).
b) A set of windows will appear, containing cell parameters data and settings, the calculated line positions for the
selected cell, and a simplified version of the summary list, in which initially the top solution will be selected. Note
that the Figure-of-Merit column ("FOM") will always contain the original merit values read from the summary file. It
is at present a limitation of Chekcell that it never recalculates any indexing figures-of-merit, even when it would
plainly be helpful to do so.
c) Simultaneously the calculated line positions will be displayed as a second set of vertical lines below the profile
baseline. These are numbered to correspond to the observed pattern and color-coded: blue if they correspond to an
indexed line (Chekcell calls this a "checked" line) and green if not observed.
d) Meanwhile the color-coding of the observed-line will change: indexed lines become blue, while unindexed ones
remain black.
5) There are now many possible routes to proceed. Here is one of them, for further evaluating the list of solutions and
trying to select the best solution and, as far as feasible, spacegroup, according to the "principle of parsimony". This
means: by selecting the trial cell (and spacegroup) that indexes the most observed lines using the least calculated lines
to do so, allowing for systematic absences. This would normally be taken into account automatically in the figure of
merit, if it could be recalculated for the revised cell/symmetry hypotheses, but, if you remember, Chekcell can't yet do
that.
a) Click the Best Solution button. A new window will appear. It is usually best to reduce the minimum number of
checked (i.e. indexed) reflections from the maximum possible, so as to see more possibilities, and perhaps some of the
other controls, such as excluding triclinic cells if some 90o angles are present). Click on Run to launch the calculation.
b) A short list of "best" cells will eventually be presented, using the parsimony principle discussed above. These are
often worth investigating further, even if they did not originally give the highest figures of merit.
6) Another important use of Chekcell is to test for the presence of a higher symmetry lattice than is apparent in the setting
reported by the indexing program:
a) Click the Le Page button. A new window will appear. Its Crystal Systems window will initially be showing "All".
Since the purpose is to see possible higher-symmetry supercells, click on only those systems that are higher than for
the present top solution. Accept the rest of the defaults and press Run.
b) If any geometrical supercells in a higher crystal system are reported, add them to the list by pressing the red Best
button. The "best solutions" section at the end of the analysis will hopefully list the possible higher-symmetry
spacegroups that this offers.
c) Note which they are, select a suitable one and press Add to add it to the summary list.
d) Click on the Close buttons for "Best" and "Le Page". The updated summary list can then be saved (in .CKM
format) by pressing the blue Save button located beneath it. This format is acceptable to the Crysfire LC (load cell)
command, so it can be reloaded into Crysfire for further investigation (for example, with an Mmap topography scan).
For further information, including examples of these and other useful operations, see the Chekcell tutorials on the CCP14
website.
36
12. Authors of contributed software
Franz Kohlbeck: Kohl [=TMO])

Arie van der Lee: Eva2Crys
Daniel Louër & A. Boultif: Dicvol
Daniel Louër: Losh, Lzon
Ton Spek (& A. Meetsma): ClePage
Daniel Taupin: Taup [=Powder]
Jan Visser: Ito, Fjzn, Lzon, etc.
Per-Eric Werner: Treor
The Open Software Movement (GNU Csort)
Robin Shirley: the overall system + Mmap, and various modifications and extensions to Lzon, Losh, Fjzn, etc.
Copyright is asserted on behalf of all authors of contributed code (copyleft in the case of Csort), and derivative copyright is
asserted by myself in any modifications that have been incorporated within the system versions, subject to the rights of the
original authors.
© 2002, etc. Authors as shown above.
12.1 Crysfire Distribution

Crysfire is distributed free for non-profit use from the CCP14 website:
http://www.ccp14.ac.uk/tutorial/crys/
It can also be licensed to industrial users - a pro-forma invoice is included.
12.2 Chekcell Distribution

Chekcell is written by Jean Laugier & Bernard Bochu, and distributed free from the CCP14 website:
http://www.ccp14.ac.uk/tutorial/lmgp/
13. This Manual

The machine-readable version of this manual distributed with Crysfire was saved in Rich Text Format by MS Word as
Crysfire.rtf. Since different Word versions (for example Word 6 and Word 97) fail to agree exactly how the format of a given
document should be interpreted, don’t be too surprised if the layout gets disturbed when printed from your system. In
particular, if preceding text expands and overruns a tab stop, then Word hurls any text sitting on that tab rightwards off the page
entirely (what great mind in Redmond dreamed up that one?). Hence, if right-hand text seems to be missing, try moving or
inserting a tab to encourage it to reappear.
Published by the Lattice Press, 41 Guildford Park Avenue, Guildford, Surrey GU2 7NL, England.
© Robin Shirley, 2002
37

CRYSFIRE

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CRYSFIRE

Încărcat de

Drepturi de autor:

Formate disponibile

Crysfire.

rtf Robin Shirley

A Powder-indexing wizard in the form of a family of DOS scripts and programs

(including scripts for running from Qdat data file formats)

1. Introduction to Crysfire 2002 and its New Features

2. What is Crysfire and what does it do?

shell=C:\WINDOWS\COMMAND.COM C:\WINDOWS /e:2048 /p

Crysfire 2002 v9.45.14 - Next command or ? for Help:

5.1 Overview of Crysfire commands listed alphabetically by command code

? or HE = HELP (general, commands, file)

5.2 Overview of Crysfire commands listed alphabetically by task/topic

HELP (general, commands, file) = ?, HE

AB = Set Bravais lattice absences OB = Input an observed pattern

RU = Run an operating system command

CD = Change default directory/drive

?,HE = HELP (general, commands, file)

HELP (general, commands, file) = ?, HE

HELP (general, commands, file) = ?, HE

Program Version Author(s) Documentation Q2{indx}**

Ito v12 (Ito12) (1994) Jan Visser Ito12.wp1 Q2IT

Dicvol Dicvol91 (1993) Daniel Louër Dicvol91.wp1 Q2DV

Treor Treor90 (1995) Per-Eric Werner Treor90.wp1 (.doc) Q2TR

Taup v3.3a (11Jun02) Daniel Taupin: Powder (1974) Taup9606.doc Q2TP

Lzon v6.23b (31Jul02) R. Shirley, D. Louër LzonData.doc (.txt) Q2LZ

Mmap v9.45.18 (2Aug02) Robin Shirley (via online help) Q2MM

ClePage v1.5 (30Apr02) Ton Spek & A.Meetsma - -

CFconfrm v1.4 Robin Shirley (8Jul02) Performs initial confirmation dialogue

Qdat v6.28L (Qdat628L) Robin Shirley (10Jul02) Indexing-data format translator

VRatio v1.2 Robin Shirley (16Jul99) Recalculates V/V1 fields in log/summary

QHead v1.2 Robin Shirley (29Jun99) Creates log/summary headings file

CSort (13Aug90) Open Software Movement Filter to sort files of strings

DelifNul v1.0 Robin Shirley (16May02) Deletes a specified file if empty

1) Crysfire home directory (as defined by the CF_Home script)

6.5 Etymological Note

7.1 General Properties

7.2 Detailed Description

Dataset header (stored as 1 line, always present):

Cell data (stored as 6-row table, only present if Ctype non-zero):

8.2 Distribution and Tutorial

For commercial distribution, please contact me at R.Shirley@surrey.ac.uk.

8.3 Conditions of Use

8.4 General Limitations

9.1 Crysfire Suite

9.2 Specific Indexing Programs

Taupin, D. (1973), A Powder-Diagram Automatic-Indexing Routine, J. Appl. Cryst., 6, 380-385.

PM Criterion (used in FJZN6 and LZON):

Ito, T. (1949), A General Powder X-Ray Photography, Nature, 164, 755-756.

10. Technical Reference Notes on Individual Indexing Programs

10.1 IT = Ito (VIsser)

Typical run times: a few seconds on a 200MHz Pentium.

usage Q2IT {datafile} {run_flag}

{run_flag} is the optional flag "-Run" which, if present, indicates that

Qdat targeted input file = {datafile}.QIT

ITO12 input data file = {datafile}.ITD

Dataset solutions-log = {datafile}.LOG

Old dataset solutions-log = {datafile}.LGK (backup)

usage Q2DV {datafile} {run_flag}

{run_flag} is the optional flag "-Run" which, if present, indicates that

Qdat targeted input file = {datafile}.QDV

DICVOL91 input data file = {datafile}.DVD

Dataset solutions-log = {datafile}.LOG

Old dataset solutions-log = {datafile}.LGK (backup)

Typical run time on a 200MHz Pentium: under a minute.

usage Q2TR {datafile} {run_flag}