|Copyright||© 2004-2015 by Global Phasing Limited|
|All rights reserved.|
|This software is proprietary to and embodies the confidential technology of Global Phasing Limited (GPhL). Possession, use, duplication or dissemination of the software is authorised only pursuant to a valid written licence from GPhL.|
|Documentation||(2004-2015) Clemens Vonrhein, Claus Flensburg, Wlodek Paciorek & Gérard Bricogne|
process -hshowing the main command-line arguments:
|-checkdeps||check for all external dependencies (and stop)|
|-check||check for all external dependencies (and stop if an error is encountered)|
|-M||<macro|file>||use a pre-defined combination of parameter settings via a macro; for a list of pre-defined macros use -M list. Alternatively, a file name with own settings (similar to a macro) can be given. See also here for details about the macro feature.|
|-I||<image directory>||directory with data images (default: current directory)|
|-d||<dir>||output will be written to [sub]directory instead of current directory|
|-R||<reslow> <reshigh>||low- and high-resolution limits (default is to use limits given by detector dimensions). Scaling/merging is allowed to limit these further based on additional criteria.|
|-[no]ANO||process for anomalous differences (default); use -noANO to switch this off (ie. assume Friedel's law holds true).|
|-B||if running in batch mode (no highlighting on standard output)|
|-ref||<MTZ file>||reference MTZ file for spacegroup, cell, indexing and (optional) test-set. The output from autoPROC will be in the same setting as this MTZ file.|
|-free||<MTZ file>||reference MTZ file (for test-set only) - if the spacegroup allows several indexing solutions at lest one set of amplitude (and sigmas) need to be present in this file. The output from autoPROC will contain this (optionally reindexed) test-set.|
to override automatic definition of identifiers/scans. Each
identifier requires 5 (comma-separated) items:
|-h5||<master.h5>||Eiger/HDF5 dataset (master file); this flag can be given several times if multiple datasets should be processed by autoPROC|
|-nthreads||<no. of threads>||how many threads should be used during parallelized steps. A negative value means: use (all)/n. (default=0 ie. do not change: from program defaults)|
|-xml||write XML file(s) containing data for deposition|
|<par>="<val>"||generic system to allow setting of parameter <par> to value <val>|
process -I /where/ever/images -d sub.dir > out.putThis will define where the images are, where output files and message should go and - if the information in the header of the images is correct (which it should be) - this is all that's needed. You can also run the command within a directory containing images (in which case the -I flag is not required) or have it create output files and directories within the current directory - it all depends on the directory layout you use and want to enforce for data-processing.
It is always a good idea to let autoPROC write all output into a separate sub-directory:
process -d <subdir>(where <subdir> could be e.g. 01 to get sequential numbering if several runs are going to be done).
Usually, the image header follows a convention that will work for a particular data processing package. As far as we know, the relation between the known data processing packages is mostly
|XDS||pixel||depends on definition of coordinate system - but often (y,x)|
|d*TREK||pixel||depends on definition of coordinate system - but often (y,x)|
process beam="1532 1582"Please note that there is a difference between the value XDS expects (detector origin) and the more easily accessible direct beam coordinates:
This can be easily visualised through a direct beam shot or ice/powder/wax rings (MOSFLM/iMOSFLM has a nice tool to fit a circle to user-selcted points, giving the centre of this circle).
If the detector is perfectly aligned (i.e. the detector normal is identical with the direct beam direction), then there is no difference in the two values. However, in reality the detector is often slightly misaligned. This results in a difference between those two points.
process BeamCentreFrom="header:y,x"This is by far the recommended way, since it only needs to be established once for a given beamline/setup. Often, some test datasets are collected on a given beamline/instrument to calibrate e.g. the beam centre values versus the detector distance. These datasets could be used to establish a possible transformation required to put the image header values (extracted with the imginfo program) into the program convention.
See also the autoPROC wiki for details regarding specific beamlines and synchrotrons.
process BeamCentreFrom="getbeam:init"This approach works surprisingly often, but is only really a stop-gap solution. Why should one re-establish the transformation between image header and program convention for every single scan/dataset over and over again - since we know it should be constant over a long time and a lot of datasets for any given beamline/setup? However, one could use this approach to get the correct transformation value and then use this with a BeamCentreFrom=header:?,? parameter from then onwards.
Or use the final reported value of direct beam coordinates and the beam8.sh jiffy in conjunction with the image header information (running imginfo) to establish the beam-centre convention used at that beamline (and ideally report this to us if it isn't already present on the autoPROC wiki).
process BeamCentreFrom="getbeam:refined"This is a fairly desperate approach, since autoPROC will try and optimise the beam centre based on some radial features present in the image background. This can be problematic for weak images, detectors with a large number of "gaps" or scaling problems between CCD modules etc.
It is always a good idea to spend a little bit of time defining the beam-stop shadow area as well as possible. Especially if several datasets with the same setup (distance etc) have been collected, the same set of parameters could be used for all runs. There are tools in all programs to help you.
XDS has more basic tools for defining the area of the detector to be ignored. Apart from the resolution limits these are
To tell XDS within autoPROC about the beamstop, one could create a text file with a set of keywords, e.g.
autoPROC_XdsKeyword_UNTRUSTED_RECTANGLE="570 1469 1920 2048|590 1369 1820 2038" autoPROC_XdsKeyword_UNTRUSTED_ELLIPSE="1510 1560 1490 1590"and run with
process -M <text file> -d <subdir>To check the effect of various settings, the BKGPIX.cbf file should be inspected - e.g. with ADXV or GPX2.
Note: in general it is also possible to mask the beamstop through a low-resolution cut-off. This is adequate if the direct beam hits a circular beamstop mid-centre. However, in cases of beamstops with other shapes or if the direct beam hits the beamstop off-centre one would need to specify a more generous low-resolution cut-off to mask out the full beamstop area (which could have negative effects on the data quality if some strong and well-defined reflexions are therefore missed).
Apart from command-line flags of the form "-<flag> [<value>]", parameters can be set using the "<par>=<val>" syntax. If a parameter should contain a (space-separated) list of values, these need to be quoted, e.g.
Remember that command-line arguments are processed in the order they are given - so later arguments can override earlier settings!
There are two main mechanisms available to pass a parameter setting to autoPROC
any command/tool will recognize a <par>=<val> string on the command-line, e.g.
process beam="1524 1532"Setting parameters this way will always override any other setting (using mechanisms described below).
The main autoPROC command process has a "-M" flag that takes as argument the name of a file. This file would then contain a set of <par>=<value> lines (one per line) and can be used with
process -M par.dat
process -d 01 beam="1524 1532" symm="P21212" cell="78 67 89 90 90 90"
A full list of parameters is available in Appendix 1.
|-mtz||<MTZ file>[:P,X,D]||multi-record MTZ file. Additionally, the explicit Pname, Xname and Dname can be given (otherwise: defaults taken as-is from header). If several MTZ files are to be used, the combine_files tool can be used to generate a single multi-record MTZ file from multiple input files (with the adequate batch-number offset required).|
|-id||<identifier>||identifier for this run (used for prefixing output files); default = 1|
|-ANO|-noANO||switch on (default) or off special treatment of anomalous differences|
|-scale||"<scale layout>"||scaling layout (see AIMLESS
default = "ROTATION SPACING 5.0 ABSORPTION 6 BFACTOR ON"
If data is below 5.0 A, we use as default = "ROTATION SPACING 5.0 ABSORPTION 6 BFACTOR OFF"
|-symm||<spacegroup>||space-group symbol; default is to take from reflection file header|
|-nres||<Nres/asu>||no. of amino-acid residues per asymmetric unit to put data on roughly absolute scale; default = 0|
|-R||<reslow> <reshigh>||resolution limits; default = "1000.0 0.1", ie all data|
|-nthreads||<no. of threads>||how many threads should be used during parallelized parts. A negative value means: use (all)/n. (default 0 ie. do not change from program defaults)|
|-freemtz||<MTZ-file>||MTZ file with existing test-set flag (to use same test-set reflections in final output MTZ files); default = ""|
|-M||<macro>||use a pre-defined combination of parameter settings; for a list of available macros use "-M list"|
|-P||<P_N> <X_N> <D_N>||triggers creation of a new dataset N description;
project, crystal and dataset name must be given.
Note: without giving this argument, the remaining arguments below will have no effect!
|-b||<B1_N>-<B2_N>[,<BN>]||for current dataset N, the batch range B1-B2 will be used (and split into separate runs using B batches for each run). If the split parameter B is given negative, then an appropriate run size will be calculated to give B separate runs. The default is to not split the current dataset into separate runs.|
|<par>="<val>"||generic system to allow setting of parameter <par> to value <val>|
More information about the scaling options available to users is available here.
For usage examples please see autoPROC wiki.
cmpmat <XPARM.XDS> <XPARM.XDS> <space group name>
|-f||<file>||unmerged reflection file|
|-P||<pname> <xname> <dname>||project, crystal and dataset name applying to the previously defined reflection file (-f flag); several -f/-P combos can be given.|
|-o||<output MTZ>||output MTZ file name|
|-ref||<reference MTZ>||reference MTZ file (to ensure consistent indexing in case alternative indexing schemes are allowed by the space group)|
|-r||run recursively (default = no)|
|-||return list suitable for automatic processing in autoPROC|
|-d||<dir>||search in directory <dir> (default = current directory)|
|-s||<min> <max>||minimum and maximum size for image files to consider (default = 512k and 98304k)|
imginfo some.cbfFor various beamline/detector/date combinations we do provide so-called 'override' functions to handle non-standard, incomplete or plainly wrong image header content. However, our goal (dream?) is that one day all image headers will be complete, unambiguous and contain correct values ...
mrfana -hThe most useful command-line options are
|-n||<nshell>||number of bins (equal volume); a negative value will do the 'standard' binning on 1/d**2|
|-nref||<nrefbin>||number of measured reflections per bin (default = 1000)|
|-r||<reslow> <reshigh>||resolution limits|