Trimming
========
We need to do 168 runs, each with 4x42 unmasked pixels, to determine
each iteration of trims. This works by calculating the highest 
undetermined bit of the six trim bits with each run set. Eight sets 
are needed; firstly for trim=0, then a set for each of the six bits 
and finally a check of the values to give the V0 version of the trim 
file. For e.g. sensor 21, the eight different run sets are labelled 
in order as
 Sensor21Trim0,
 Sensor21Bit0,
 Sensor21Bit1,
 Sensor21Bit2,
 Sensor21Bit3,
 Sensor21Bit4,
 Sensor21Bit5,
 Sensor21TrimV0

A run set is done using
 runStart -t mpsMaskThresholdScan -v 21 -n 168
Summary files of means and noise for the unmasked pixels are
created for each run using mpsAnalysis. The whole run set can be
done in one go with
 mpsAnalysis -n 168 <first-run-number>
This produces 168 separate files, each named 
 MpsAnalysisMaskThresholdScan<run-number>.txt
For each run set, these are combined into one file for all pixels
using mpsMaskThresholdScanCombine. This needs to be edited for
each run set to specify the runs used and then rebuilt
 build mpsMaskThresholdScanCombine
It is called by
 mpsMaskThresholdScanCombine Sensor21Bit3
for example. This will print out missing or duplicated pixels.
Missing ones can be due to too high a trim, which pushes the
hits outside the threshold range used, so no hits are seen.
The subsequent software will handle these OK. Duplicates are 
always an error and so if they occur, they may need masking
later by hand so note which pixels appear twice.

The combined files for the various run sets of one sensor
are processed using mpsMaskThesholdScanTrim, using e.g.
 mpsMaskThesholdScanTrim Sensor21
This produces quite a bit of output so pipe into a file, e.g.
 mpsMaskThesholdScanTrim Sensor21 > temp.log
and check the file for problems. Search for "mean" to see the
trim values which are being changed. Searching for "mean 0" should
give missing pixels and these should normally have very high trim
values (~48 or above). This program produces a configuration file 
called Sensor21.cfg which must then be copied into the local online 
working cfg/ directory before the next run set begins
 mv Sensor21.cfg ~/online/cfg/MpsSensor1ConfigurationDataSensor21.cfg
Note, this means a file will all trims set to zero for a new sensor 
must be put in the online/cfg directory before starting the whole 
trim process.

The most common error is that the sensor configuration data
is randomly reset during a run. This removes the mask of the other
pixels and so increases the data volume enormously. Such files are
easy to spot as the data file size, shown using
 ls -l data/run
is much larger than for all the other files. It is common to get
one or two such large files in each run set. In such cases, the 
corrupted runs must be retaken by hand. This requires a shutDown
of the DAQ, editing MpsConfiguration.hh, then
 build runner
 startUp
and then taking one replacement run
 runStart -t mpsMaskThresholdScan -v 21
The change to MpsConfiguration.hh is to cludge it to start with
a different value for _runNumberInSequence. Specifically, uncomment

        //unsigned save=_runNumberInSequence;
        //_runNumberInSequence=426185-426157;
	...
        //_runNumberInSequence=save;

and set the two run numbers to the corrupted value minus the
first run number of the set. Do not forget to re-comment these
lines before taking the next full set of runs! This also means the
run list in mpsMaskThresholdScanCombine.cc will need to be fiddled
to pick up the re-taken run rather than the original; there are
many examples of this already in this code.

Try not to let mpsMaskThresholdScanCombine.cc get out of synch
if running trims in parallel on more than one system.