The code for the denoising is generally organized into header-only classes or namespaces;
this doesn't match what most of EXOAnalysis does.  However, it is easier to work with
the build process when there are no intermediate object files or libraries (helpful particularly
when we are sometimes seeking a static build), and header-only code offers the maximum
opportunity for the compiler to do optimizations.

Nevertheless, this doesn't help a new user to separate interface (and particularly the public
interface) from implementation.  If we want to be serious about this, the right solution
is to use doxygen or cldoc to extract the interface.  I have attempted to provide extensive
comments throughout, but you would need to do the work of converting them to markup which
can be parsed by these programs.

The code is organized as follows:
* Utilities: helper C++ code which is used elsewhere.
* NoiseCorrelations: classes related to handling the correlation information for noise on different channels.
* LightMap: the functions R(x) and S(t) which define APD yield, and related classes.
* External: code pulled in from elsewhere (currently sqlite).  Consider updating it once in a while.
* Scripts: python scripts which demonstrate typical usage of the executables and perform other useful functions.

Additionally, some of the code creates or uses a folder called Tmp; output to this directory should not be committed, but may be worth keeping for your own purposes.  For instance, this is where the database of thorium full-energy events gets placed before being built into a lightmap.

Executables themselves are currently put into the base directory, but that may change.


===============================================================================
TO GENERATE A LIGHTMAP

On SLAC, from the base directory of this repository, run:

1) bsub -q xxl -R rhel60 -o RunComputeRotationAngle.log python Scripts/RunComputeRotationAngle.py

The purpose of this script (which calls ComputeRotationAngle.py) is to locate the thorium peak position and optimal angle.  We already run ComputeRotationAngle.py -- a different version -- on the pipeline, but that version only takes events with nsc = 1 so it is not correct for strong source runs.  Someone should fix this, and then we wouldn't have to rerun it over all data ourselves.  If you do fix it, be careful -- currently we trust the ComputeRotationAngle script to reject non-Th runs, but if someone else's version works on non-Th runs then we'll need to do the check elsewhere.

This script does not expect every run to succeed; some fail for good reasons.  However, any run which fails will not be included in the lightmap, so it would be good to make it as robust as possible.

With good queue availability, this takes around one hour.

2) bsub -q xxl -R rhel60 -o BuildThEventDatabase.log python -u Scripts/BuildThEventDatabase.py

Now that we've identified the thorium peak on a run-by-run basis, along with the optimal rotation angle and the resolution, build a database of full-energy single-site thorium events.  At the end, statistics are printed to indicate why runs and events were cut.

This takes around 15 hours to run, and produces a roughly 2GB database of ~1.8 million usable scintillation clusters.

3) bsub -q xxl -R rhel60 -o BuildLightMap.log ./BuildLightMap

Use the database of full-energy single-site thorium events to build a lightmap.  It will be saved in Tmp/LightMap.hdf5.  (If a file already exists there, it will fail.)

The laser run data is also incorporated here to ensure that S(t) is genuinely the APD gain, and not some scaled version; the rest is absorbed into R(x).  Note that electronics gains are not included in S(t) currently.

This takes about 7 hours to run, and produces an 18MB lightmap file.

===============================================================================
TO GENERATE NOISE CORRELATION FILES

On SLAC, from the base directory of this repository, run:

python Scripts/GenerateNoiseCorr.py

The resulting noise correlation files go into the Tmp directory, and are about 400 MB each.
Note that if there are destination files in the way, then the jobs will fail rather than overwrite them.
You should be sure to check the log files to verify that all jobs succeeded.