2 files changed, 11 insertions, 13 deletions
diff --git a/doc/man/indexamajig.1 b/doc/man/indexamajig.1
index 3f49701f..8bef2e5e 100644
--- a/doc/man/indexamajig.1
+++ b/doc/man/indexamajig.1
@@ -89,7 +89,7 @@ You can add one or more of the following to the above indexing methods, to contr
 
 .IP \fB-latt\fR
 .PD
-Provide the Bravais lattice type (e.g. the knowledge that the lattice tetragonal primitive), as prior information to the indexing engine.
+Provide the Bravais lattice type (e.g. the knowledge that the lattice is tetragonal primitive), as prior information to the indexing engine.
 
 .IP \fB-nolatt\fR
 .PD
@@ -101,7 +101,7 @@ Provide your unit cell parameters as prior information to the indexing engine.
 
 .IP \fB-nocell\fR
 .PD
-The opposite of \fB-cell\fR: do not use unit cell parameters as prior information for the core indexing algorithm.
+The opposite of \fB-cell\fR: do not provide unit cell parameters as prior information to the indexing engine.
 
 .PP
 Example: \fB--indexing=mosflm-cell-latt\fR means to use Mosflm for indexing, and provide it with unit cell parameters and Bravais lattice type information.
@@ -112,7 +112,7 @@ The default indexing method is 'none', which means no indexing will be done.  Th
 .PP
 You do not need to explicitly specify anything more than the indexing method itself (e.g. \fBmosflm\fR or \fBasdf\fR).  The default behaviour for all indexing methods is to make the maximum possible use of prior information such as the lattice type and cell parameters.  If you do not provide this information, for example if you do not give any unit cell file or if the unit cell file does not contain cell parameters (only lattice type information), the indexing methods you give will be modified accordingly.  If you only specify the indexing methods themselves, in most cases \fBindexamajig\fR will do what you want and intuitively expect!  However, the options are available if you need finer control.
 
-If you don't know what to give for this option, try \fB--indexing=asdf,dirax,mosflm,xds,taketwo\fR.
+If you don't know what to give for this option, leave it out completely.  Indexamajig will then automatically select indexing methods based on the programs available on your computer.
 
 The indexing results from the indexing engine will be put through a number of refinement and checking stages.  See the options \fB--no-check-cell, --no-cell-combinations, --no-multi, --no-retry\fR and \fB--no-refine\fR below for more details.
 
@@ -305,7 +305,7 @@ With this option with \fB--peaks=hdf5\fR, the peaks will additionally be checked
 .PD 0
 .IP \fB--indexing=\fR\fImethod\fR
 .PD
-Index the patterns using \fImethod\fR.  See the section titled \fBINDEXING METHODS\fR (above) for more information.  The default is \fB--indexing=none\fR.
+Index the patterns using \fImethod\fR.  See the section titled \fBINDEXING METHODS\fR (above) for more information.  The default is to automatically detect which indexing methods to use.
 
 .PD 0
 .IP "\fB-p\fR \fIunitcell.cell\fR"
@@ -332,9 +332,9 @@ Do not check the cell parameters against the reference unit cell (given with \fB
 When checking the cell parameters against the reference cell (see \fB-p\fR), do not make combinations of the axes of the candidate cell (such as \fBa'\fR=2\fBa\fR+\fBb\fR) to make it fit.  Usually this reduces the success rate, but is necessary if one of the cell parameters is close to a multiple of the others.  \fRThis happens for tetragonal lysozyme\fB.
 
 .PD 0
-.IP \fB--no-multi
+.IP \fB--multi
 .PD
-Disable multi-lattice indexing.  This refers to the "subtract and retry" method, where after a successful indexing attempt the spots accounted for by the indexing solution are removed before trying to index again in the hope of finding a second lattice.  This doesn't have anything to do with the multi-lattice indexing algorithms such as Felix.
+Enable the "subtract and retry" method, where after a successful indexing attempt the spots accounted for by the indexing solution are removed before trying to index again in the hope of finding a second lattice.  This doesn't have anything to do with the multi-lattice indexing algorithms such as Felix.
 
 .PD 0
 .IP \fB--no-retry
diff --git a/doc/man/partialator.1 b/doc/man/partialator.1
index 0a5b78ba..aa25d2a7 100644
--- a/doc/man/partialator.1
+++ b/doc/man/partialator.1
@@ -155,7 +155,7 @@ If you prefer, you can specify the ambiguity operator by specifying the apparent
 .IP \fB--force-bandwidth=\fIbw\fR
 .IP \fB--force-radius=\fIR\fR
 .PD
-Set the X-ray bandwidth or initial profile radius for all crystals before proceeding.  Bandwidth is given as a fraction, i.e. \fB--force-bandwidth=0.0013\fR means 0.13 percent (approximate FWHM).  Radius is given in  nm^-1.
+Set the X-ray bandwidth or initial profile radius for all crystals before proceeding, overriding the values from the stream.  Bandwidth is given as a fraction, i.e. \fB--force-bandwidth=0.0013\fR means 0.13 percent (approximate FWHM).  Radius is given in  nm^-1.
 
 .SH PARTIALITY MODELS
 
@@ -190,15 +190,15 @@ partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=uni
 
 .IP "Merging with partialities, but without post-refinement and without scaling:"
 .PD
-partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=scsphere --iterations=0\fR
+partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=xsphere --iterations=0\fR
 
 .IP "Merging with partialities, with scaling but without post-refinement:"
 .PD
-partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=scsphere --iterations=1 --no-pr\fR
+partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=xsphere --iterations=1 --no-pr\fR
 
 .IP "Merging with partialities, post-refinement and scaling:"
 .PD
-partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=scsphere --iterations=1\fR
+partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=xsphere --iterations=1\fR
 .IP
 (Use a higher number of iterations to increase the accuracy of scaling and post-refinement, but at a cost of more CPU time and possibly more rejected crystals)
 
@@ -206,11 +206,9 @@ partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=scs
 .PD
 This would be a strange thing to want to do, however:
 .IP
-partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=scsphere --iterations=1 --no-scale\fR
+partialator -i \fImy.stream \fR-o \fImy.hkl\fR -y \fImypointgroup \fB--model=xsphere --iterations=1 --no-scale\fR
 .IP
 (Use a higher number of iterations to increase the accuracy of post-refinement, but at a cost of more CPU time and possibly more rejected crystals)
-.PP
-\fBscguassian\fR could be substituted for \fBscsphere\fR in the above examples to use the Gaussian partiality model instead of the spherical one.
 
 .SH CUSTOM DATASET SPLITTING
 When performing a time-resolved experiment (for example), it is preferable to ensure that the data for all time points has been processed identically.  Rather than processing each time point independently with separate runs of partialator, it is better to process them all together and do the splitting into time points just before the final output.  Consider, for example, the case of simple scaling (without a B factor): when merging independently, the resulting datasets would probably end up with different overall scaling factors.  When comparing the results, you would need to take this difference into account.  In practice, most programs can do that job easily, but what about if a B factor is included?  And what if partialities are included - how unique is the solution?