CRYSFIRE.doc Robin Shirley

V3.01 27Jul99

[This document has been formatted for a Postscript printer in 10pt New Century Schoolbook;

if not available, try 10pt Times. Saved in Rich Text Format by MS Word as CRYSFIRE.rtf]

Some user 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 eight of the principal powder-indexing programs automatically under MSDOS (either directly or in a Windows DOS box), taking their input data from either a CRYS dataset (CRYSFIRE), or a dataset in a QDAT input file (for Q2{indx}), or from a dataset in that indexing program’s native input file format (for RUN{indx}). [For more about powder indexing in general, see KYOTINDX.wp1.]

The present distribution includes the CRYS program (which acts as interactive front-end and indexing wizard), the various indexing programs, other associated programs, a quantity of documentation and example runs, and two programs (WF2CRYS and XF2CRYS) for importing data from peaks-list files written respectively by the profile-fitting programs WinFit and XFIT.

As mentioned, the subsidiary Q2{indx} scripts require QDAT-format input files. These will typically have been written by CRYS 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).

Native-format files for RUN{indx} will usually have been written by QDAT, in the course of a previous run of Q2{indx} (usually under CRYSFIRE), and then hand-edited to adjust special features of the indexing program(s) concerned.

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} and RUN{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: MSDOS EDIT; display omitted 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 LOSHFZRF to be supported as QDAT targets, the QDAT version used must be at least v6.23 (i.e. QDAT623), and preferably at least v6.25 to support LZON’s NRLOSH parameter. Similarly, TAUP requires QDAT v6.27c (QDAT627) and CRYS v9.31b (CRYS931) or later. 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 intended to be installed into a single directory (for example, C:\CRYSFIRE), which needs to be on the MSDOS execution path if you intend to call them from other (data) directories. So either 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.

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).

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: MSDOS EDIT).

The following indexing programs are supported in the current CRYSFIRE distribution (with the latest version tested shown in column 2):

ITO v12 (ITO12) (1994) Jan Visser ITO12.wp1 Q2IT RUNIT

DICVOL DICVOL91 (1993) Daniel Louër DICVOL91.wp1 Q2DV RUNDV

(& DICVOLG)

TREOR TREOR90 (1995) Per-Eric Werner TREOR90.wp1 (.doc) Q2TR RUNTR

TREOR90.sht

TAUP v3.2c (8Jul99) Daniel Taupin (1974) TAUP9606.doc Q2TP RUNTP

(+ mods by R. Shirley)*

KOHL v6.20h (30Jun99) Franz Kohlbeck (1975) (To follow) Q2KL RUNKL

(+ mods by R. Shirley)*

FJZN6 v6.21a (FJZN621) Jan Visser & R. Shirley (much of ITO12.wp1 Q2FJ RUNFJ

(9Jul99) applies)

LZON v6.22g (LZON622) R. Shirley, D. Louër LZONDATA.doc (.txt) Q2LZ RUNLZ

(14Jul99) & Jan Visser

LOSH LOSHFZRF D. Louër & R. Shirley* (To follow) Q2LS RUNLS

(LOSHFZ61)

v6.1a (15Jul96)

* with FZRF cell refinement & evaluation appended from Jan Visser's ITO6

After some 3 months of intensive development (April – July 1999), CRYSFIRE is now reasonably complete, but suggestions for improvement are welcomed and it is hoped that further indexing programs may be added as opportunity permits. To be a candidate for support by CRYSFIRE, an indexing program should be able to run in c.550KB within an MS-DOS environment under Windows 3.x, 95, etc., (without needing a DOS extender), able to use powder-line positions (rather than require full profiles), and be sufficiently mature for CRYS to be supplied with 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 very efficient and well suited to these compact but computationally intensive programs. A protected-mode Windows version of LZON turned out to run 3 times slower than the otherwise-identical DOS version (in a DOS box under Windows 95).

There are no plans to produce a 32-bit Windows version of CRYSFIRE as such, but instead to move on towards a more ambitious 32-bit replacement, provisionally called the Indexer’s WorkBench, supported under both 32-bit Windows and Linux and developed by a virtual team working via the internet. It is early days yet, but if you are interested in becoming involved in this project, please contact R.Shirley@surrey.ac.uk.

Associated CRYSFIRE software:

CRYSFIRE (for CRYS v9.33) Robin Shirley (19Jul99) Master automatic-indexing script

CRYS v9.33e (CRYS933) Robin Shirley (25Jul99) Powder diffraction utility / indexing wizard

QDAT v6.28c (QDAT628) Robin Shirley (15Jul99) Indexing-data format translator

ITLOG v1.3 Robin Shirley (29Jun99) Log/summary post-processor for ITO12

DVLOG v1.0 Robin Shirley (29Jun99) Log/summary post-processor for DICVOL91

TRLOG v1.0 Robin Shirley (6Jul99) 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

MERGESUM - Robin Shirley (19Jul99) Merges two CRYSFIRE summary files

WF2CRYS v1.6c Robin Shirley (3Jun99) Converts WinFit peaks file to CRYS dataset

X2CRYS v1.6c Robin Shirley (3Jun99) Converts XFIT peaks file to CRYS dataset

Disclaimer

With so much esoterica to sift through and intricate hierarchies of parameters to disentangle, it would be amazing if the following 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 in a rush as a final task after the completion of program development and testing, with many major changes to be accommodated and two completely new indexing targets to include, so it would be prudent to regard the detailed information here as provisional. Naturally I’ve tried to make it accurate, but this is far from guaranteed. If you come across what seem to be errors, please let me know at R.Shirley@ surrey.ac.uk.

CRYSFIRE is the new name for CRY2RUN II, now renamed to emphasise the major changes in scope and functionality in this greatly enhanced release. Apart from the addition of several new indexing targets, there are many new features, such as targeted QDAT files, cumulative log and summary files for each dataset, the import of WinFit and XFIT peaksearch files, and much more. The name "CRYSFIRE" reflects the multi-target scattershot approach promoted by Lachlan Cranswick in his CCP14 website tutorials (who, as you can see, succeeded in wearing down my resistance to what I saw as the de-skilling of powder indexing). It brings echoes too of "crossfire" (between the different programs?) and "quickfire" (how, hopefully, it will operate). And perhaps a reference somewhere to the fiery furnace into which I was pitched while developing it. (R.S.)

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 CRYSFIRE system as a whole, including its scripts and associated programs (CRYS, QDAT, ITLOG, DVLOG, TRLOG, VRATIO, QHEAD, WF2CRYS and XF2CRYS) listed above , are all © R.Shirley, 1999.

Similarly, copyright is reserved by the various authors of the indexing programs, including myself. The derivative copyright in my adaptations and extensions to the indexing programs is © R.Shirley, 1999, subject to the permission of the authors of the relevant base versions of the programs.

For commercial licences covering material for which I hold the copyright, and for confidential consultancy, please contact me at R.Shirley@surrey.ac.uk.

The CRYSFIRE suite is distributed free for non-profit use via the CCP14 web site (http://www.ccp14.ac.uk), where several detailed tutorials have been provided by Lachlan Cranswick. It is also hoped to be included in subsequent versions of the CCP14 CD-ROM.

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

For non-profit use, the following conditions apply:

2. 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 are given below).

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

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

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.

Wolff, P. M. de (1963), Indexing of Powder Diffraction Patterns, Adv. X-Ray Anal., 6, 1-17.

Wolff, P. M. de (1972), The definition of the indexing figure of merit M₂₀, J. Appl. Cryst., 5, 243.

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. (See also FJZN6 for a variant that will sometimes succeed where ITO12 fails.)

Q2IT Runs the ITO12 zone-indexing program automatically on the dataset given in targeted QDAT input file %1.QIT (written, for example, by CRYS), using QDAT/ITO12 defaults unless specified otherwise. Typical run times: a few seconds on a 200MHz pentium.

usage Q2IT {datafile}

(i.e. without its .QIT extension)

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

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNIT Runs the ITO12 zone-indexing program automatically on the dataset given in ITO12 input file %1.ITD (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. ITO12 defaults unless specified otherwise).

usage RUNIT {datafile}

(i.e. without its .ITD extension)

[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)]

Exhaustive search in parameter space by successive dichotomy

Being an exhaustive program, 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 400A³ shells of increasing cell volume, which means that low-volume solutions may be 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. So, if an orthorhombic solution is reported and a hexagonal one suspected, this can be tested by making a further run (with RUNDV), manually 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.

Q2DV Runs the DICVOL91 indexing program automatically on the dataset given in targeted QDAT input file %1.QDV (written, for example, by CRYS), using QDAT/DICVOL91 defaults unless specified otherwise. Typical run times on a 200MHz Pentium: a few seconds down to orthorhombic, 5-30 minutes for a monoclinic search, much longer to complete triclinic, depending very much on cell volume

Q2DVG An older, non-targeted script that calls the extended version DICVOLGV instead of DICVOL91. Otherwise it runs similarly, except that a .QDT file is expected, no log or summary is produced, and DICVOLGV will ask for the name of its input file - {datafile}.DVD, and output file - e.g. {datafile}.DVO, where {datafile} is the dataset name. DICVOLGV is roughly twice as fast as DICVOL91 but considerably tighter on base RAM, so may be unable to run if much base RAM has been lost to network drivers, etc.

Defaults Crystal systems: down to triclinic. VOLMAX: 6000 BEMAX: 130 deg

EPS (±2Theta limits on observed lines): 0.04 (CRYS), 0.03 (QDAT, DICVOL91)

To change these, edit {datafile}.DVD and use RUNDV (or run DICVOLG manually).

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.

Although DICVOL uses the optimal exhaustive algorithm in parameter space (a form of binary search), like all exhaustive indexing programs it can become very time-consuming in low symmetry. Thus it's usually more effective to seek triclinic solutions with ITO12, TREOR90, KOHL and LZON before running a triclinic scan with DICVOL. CRYS (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).

If DICVOL needs to be interrupted with Ctrl-Break (or Ctrl-C), it’s then 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 proceed to the log/summary processing.

usage Q2DV {datafile}

(i.e. without its .QDV extension)

QDAT targeted input file = {datafile}.QDV

QDAT output listing file = {datafile}.QDO

DICVOL91 input data file = {datafile}.DVD

DICVOL91 output file = {datafile}.DVO

DICVOL91 solutions-log = {datafile}.DVG

DICVOL91 solutions-summary = {datafile}.DVM

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNDV Runs the DICVOL91 indexing program automatically on the dataset given in DICVOL input file %1.DVD (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. QDAT/DICVOL91 defaults unless specified otherwise).

If triclinic searches have been enabled, DICVOL91 will continue into lengthy low-symmetry (monoclinic and triclinic) searches, although a possible solution may already have been found in higher symmetry. These can be halted by Ctrl-Break if necessary, and the output checked to see whether the low-symmetry searches are really needed (see notes on Q2DV above).

usage RUNDV {datafile}

(i.e. without its .DVD extension)

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 CRYS), using QDAT/TREOR90 defaults unless specified otherwise. 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 RUNTR.

usage Q2TR {datafile}

(i.e. without its .QTR extension)

QDAT targeted input file = {datafile}.QTR

QDAT output listing file = {datafile}.QDO

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

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNTR Runs the TREOR90 indexing program automatically on the dataset given in TREOR90 input file %1.TRD (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. TREOR90 defaults unless specified otherwise).

usage RUNTR {datafile}

(i.e. without its .TRD extension)

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 CRYS), using QDAT/TAUP defaults unless specified otherwise.

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 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 then 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 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 M₂₀ = 7)

NSPURI=0 (2nd parameter on line 2 - can be edited then re-run with RUNTP)

±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 RUNTP.

usage Q2TP {datafile}

(i.e. without its .QTP extension)

QDAT targeted input file = {datafile}.QTP

QDAT output listing file = {datafile}.QDO

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

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNTP Runs Taupin’s index-permutation program automatically on the dataset given in TAUP input file %1.TPD (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. TAUP defaults unless specified otherwise).

usage RUNTP {datafile}

(i.e. without its .TPD extension)

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 which 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, 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 supported by CRYS).

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.

Q2KL Runs Kohlbeck’s index-space program automatically on the dataset given in targeted QDAT input file %1.QKL (written, for example, by CRYS), using QDAT/KOHL defaults unless specified otherwise. 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. Happily the different searches are independent, so that a further run that starts after the offending search may well proceed correctly.

Defaults All searches enabled (orthorhombic, monoclinic and triclinic)

usage Q2KL {datafile}

(i.e. without its .QKL extension)

QDAT targeted input file = {datafile}.QKL

QDAT output listing file = {datafile}.QDO

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

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNKL Runs Kohlbeck’s index-space program automatically on the dataset given in KOHL input file %1.TKL (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. KOHL defaults unless specified otherwise).

usage RUNKL {datafile}

(i.e. without its .KLD extension)

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.

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.

(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 CRYS), using QDAT/FJZN6 defaults unless specified otherwise.

Typically this takes a few seconds on a 200MHz Pentium.

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 RUNTP.

usage Q2FJ {datafile}

(i.e. without its .QFJ extension)

QDAT targeted input file = {datafile}.QFJ

QDAT output listing file = {datafile}.QDO

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

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNFJ Runs the modified FJZN6 version of Visser’s ITO6 zone-indexing program automatically on the dataset given in FJZN6 input file %1.FJD (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. FJZN6 defaults unless specified otherwise).

usage RUNFJ {datafile}

(i.e. without its .FJD extension)

Note that datafiles for ITO12 and LZON are not directly compatible with FJZN6 unless their second parameter line is deleted.

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.

Its 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 limit of 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 only be based 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 LZON622 indexing program automatically on the dataset given in targeted QDAT input file %1.QLZ (written, for example, by CRYS), using QDAT/LZON622 defaults unless specified otherwise (effectively the same format as for ITO12)

Defaults NZ1: 8 (use top 8 zones as basis zones)

NZ2: 0 (don't rerun any basis zones with basis line as 002 [unless the zone is

rectangular or centred])

WAVEL: 1.5406 (CuKa 1 wavelength in Angstroms)

D2THDF: ±2Theta limits on observed lines: 0.04 (CRYSFIRE), 0.03 (QDAT), 0.06 (LZON)

ALPMIN: 30 (minimum alpha* in degrees)

BETMIN: 30 (minimum beta* in degrees)

VOLMAX: 1500+ (estimated automatically from the first 3 observed lines)

NSPURI: 0 (i.e. no unindexed lines permitted)

usage Q2LZ {datafile}

where {datafile} is the base name of the %1.QLZ targeted QDAT input file

(i.e. without its .QLZ extension)

The same {datafile} name is used automatically when naming all subsequent files in the run:

QDAT targeted input file = {datafile}.QLZ

QDAT output listing file = {datafile}.QDO

LZON622 input data file = {datafile}.LZD

LZON622 main output file = {datafile}.LZO

LZON622 short output file = {datafile}.LZS

LZON622 input verification = {datafile}.LZV

LZON622 solutions-log = {datafile}.LZG

LZON622 solutions-summary = {datafile}.LZM

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNLZ Runs the LZON622 indexing program automatically on the dataset given in LZON input file %1.LZD (written, for example, by QDAT), using whatever control parameters are specified in the data file (i.e. LZON622 defaults unless specified otherwise - effectively the same format as for ITO12)

usage RUNLZ {datafile}

where {datafile} is the base name of the %1.LZD LZON input file

(i.e. without its .LZD extension)

[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)]

Exhaustive search of alpha* & beta* in parameter space

by successive dichotomy, for specified basis sets

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).

This process 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 zones listings in the main output files of ITO12, FJZN6 or LZON, seeking a promising prospect that the original program missed. This will typically be one with relatively large reciprocal area (hence small direct-cell constants) and large coverage (few unobserved lines within the zone). 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 CRYS).

Q2LS Runs 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. 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 are in the original French (their meaning will hopefully still be obvious).

ALPMIN,BETMIN: 30 (minimum alpha* & beta* in degrees)

Datafile format for Q2LS (i.e. A datafile for QDAT, with LOSHFZRF as target – this will be generated automatically by CRYS (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):

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}

where {datafile} is the base name of the %1.QLS targeted LOSHFZRF input file

(i.e. without its .QLS extension)

The same {datafile} name is used automatically when naming all subsequent files in the run:

QDAT targeted input file = {datafile}.QLS

QDAT output listing file = {datafile}.QDO

LOSHFZRF input data file = {datafile}.LSD

LOSHFZRF output file = {datafile}.LSO

LOSHFZRF solutions-log = {datafile}.LSG

LOSHFZRF solutions-summary = {datafile}.LSM

Dataset solutions-log = {datafile}.LOG

Dataset solutions-summary = {datafile}.SUM (sorted)

Dataset solutions-summary = {datafile}.SMH (sorted and with headings)

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

Old dataset solutions-summary = {datafile}.SUM (backup)

RUNLS Runs LOSHFZRF indexing program automatically on the dataset given in LOSHFZRF input file %1.LSD, including a specified basis set but using all LOSHFZRF defaults unless specified otherwise.

ALPMIN,BETMIN (line 3, cols 1-14: 2F7.2): (min alpha*, beta* degrees, no defaults)

usage RUNLS {datafile}

where {datafile} is the base name of the %1.LSD LOSHFZRF input file

(i.e. without its .LSD extension)

The machine-readable version of this manual distributed with CRYSFIRE was saved in Rich Text Format by MS Word as CRYSFIRE.rtf. Since Word 6 and Word 7 don’t agree too well among themselves exactly how the format of a given document should be interpreted, don’t be 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 mastermind 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 5NL, England.

© Robin Shirley, 1999