Idea to extend CCP4 cif2mtz to handle new data types better in the future.

  • Names looked for by cif2mtz not present in mmCIF dictionary could be handled better:
    • Option to warn/skip over those names rather than abort
    • Give all missing item names on abort, rather than aborting on the first one.
  • Full runtime configuration of item names in the REFLN category (subject to a hard-coded maximum number)
    • Would require preparation of a file something like this, which is read at runtime and used to overwrite the initialised contents of cifrnames, lsprgo and ctprgo
H H _refl.index_h
K H _refl.index_k
L H _refl.index_l
FREE I _refln.status
FP F _refln.F_meas_au 
SIGFP Q _refln.F_meas_sigma_au
  • This file would define the order of the columns in the resulting MTZ file, which is reasonable behaviour I think. It would have to be matched to a compatible dictionary, and referred to with an environment variable or CCP4 logical unit.
  • In the current code there is an assumption that _refln.status is the 4th item (and maybe other similar assumptions?), but these assumptions can be removed without much difficulty.
  • cif2mtz also gets some data from the following mmCIF categories (when present in file, and values not defined in keyworded input):
    • CELL: _cell.length_a/b/c, _cell.angle_alpha/beta/gamma, _cell.volume
    • SYMMETRY: _symmetry.Int_Tables_number, _symmetry.space_group_name_H-M
    • DIFFRN:
    • ENTRY:
  • These are pretty generic and stable: can these remain as hard-coded (i.e. would we ever expect to have to use a dictionary with cif2mtz where these items are not defined)? Probably OK to leave hard-coded....

Page by Peter Keller original version 21 Dec 2011. Address problems, corrections and clarifications to