diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/man/crystfel.7 | 2 | ||||
| -rw-r--r-- | doc/man/indexamajig.1 | 59 |
2 files changed, 1 insertions, 60 deletions
diff --git a/doc/man/crystfel.7 b/doc/man/crystfel.7 index 711b7552..3efb3004 100644 --- a/doc/man/crystfel.7 +++ b/doc/man/crystfel.7 @@ -84,7 +84,7 @@ the list of examples on the CrystFEL website. .SH SYMMETRY IN CRYSTFEL Without only a very few exceptions, CrystFEL is not interested in space groups. Instead, it deals with point groups which embody the information about how data should be merged from different crystals. Every space group belongs to exactly one point group, and you can look up the right one in the International Tables or using the symmetry tables accompanying the CrystFEL source (or to be found on the CrystFEL website in the Theory section). -A limitation of symmetry in the current version of CrystFEL is that it can only accept point groups in standard settings. That means that the highest-order rotation axis must always be parallel to c*, monoclinic unit cells should have \fIc\fR as the unique axis and so on. This is a limitation of the way your input, for example using the \fB-y\fR argument of \fBprocess_hkl\fR, is turned into CrystFEL's internal representation of symmetry, and so future versions should very soon be able to handle any setting. +You can append \fB_ua\fR\fIX\fR to any of the point group symbols listed below, where \fIX\fR is \fBa\fR, \fBb\fR or \fBc\fR. This will specify the 'unique' axis for lattices which have one. The options are: diff --git a/doc/man/indexamajig.1 b/doc/man/indexamajig.1 index 5bc3f7c0..de95e307 100644 --- a/doc/man/indexamajig.1 +++ b/doc/man/indexamajig.1 @@ -318,65 +318,6 @@ Normally, indexamajig will check that the projected reciprocal space positions o .PD Don't subtract local background estimates from integrated intensities. This is almost never useful, but might help to detect problems from troublesome background noise. -.PD 0 -.IP \fB--cpus=\fR\fIn\fR -.IP \fB--cpugroup=\fR\fIn\fR -.IP \fB--cpuoffset=\fR\fIn\fR -.PD -See the section below about \fBTUNING CPU AFFINITIES FOR NUMA HARDWARE\fR. Note in particular that \fB--cpus\fR is not the same as \fB-j\fR. - - - -.SH TUNING CPU AFFINITIES FOR NUMA HARDWARE - -If you are running indexamajig on a NUMA (non-uniform memory architecture) -machine, a performance gain can sometimes be made by preventing the kernel from -allowing a process or thread to run on a CPU which is distant from the one on -which it started. Distance, in this context, might mean that the CPU is able to -access all the memory visible to the original CPU, but perhaps only relatively -slowly via a cable link. In many cases a group of CPUs will have direct access -to a certain region of memory, and so the process may be scheduled on any CPU in -that group without any penalty. However, scheduling the process to any CPU -outside the group may be slow. When running under Linux, indexamajig is able to -avoid such sub-optimal process scheduling by setting CPU affinities for its -threads. The CPU affinities are also inherited by subprocesses (e.g. MOSFLM or -DirAx). - -To do this usefully, you need to give indexamajig some information about your -hardware's architecture. Specify the size of the CPU groups using -"--cpugroup=<n>". You also need to specify the overall number of CPUs, so that -the program knows when to 'wrap around'. Using "--cpuoffset=<n>", where "n" is -a group number (not a CPU number), allows you to manually skip a few CPUs, which -may be useful if you do not want to use all the available CPUs but want to avoid -running all your jobs on the same ones. - -Note that specifying the above options is NOT the same thing as giving the -number of analyses to run in parallel (the 'number of threads'), which is done -with "-j <n>". The CPU tuning options provide information to indexamajig about -how to set the CPU affinities for its threads, but it does not specify how many -threads to use. - -Example: 72-core Altix UV 100 machine at the author's institution - -This machine consists of six blades, each containing two 6-core CPUs and some -local memory. Any CPU on any blade can access the memory on any other blade, -but the access will be slow compared to accessing memory on the same blade. -When running two instances of indexamajig, a sensible choice of parameters might -be: - -.PP -Instance 1: --cpus=72 --cpugroup=12 --cpuoffset=0 -j 36 -.PP -Instance 2: --cpus=72 --cpugroup=12 --cpuoffset=36 -j 36 - -This would dedicate half of the CPUs to one instance, and the other half to the -other. - - -.SH A NOTE ABOUT UNIT CELL SETTINGS - -At the moment, CrystFEL's core symmetry module only knows about one setting for each unit cell. You must use the same setting for now, but this will be improved in future versions. The cell settings are the standard ones from the International Tables (2006). That means, for example, that for orthorhombic cells in point group mm2 the twofold axis should be along "c", i.e. no mirror perpendicular to "c". For tetragonal cells and hexagonal lattices, the unique axis should be "c" as usual. For monoclinic cells, the unique axis must be "c". - .SH BUGS Don't run more than one indexamajig jobs simultaneously in the same working |