Monte Carlo
Validation

digiRootData
 Validation 

New Monte Carlo Output
When processing an IRF (instrument response file) created by a simulation, we also desire to store the Monte Carlo data.  Previously, RootWriter ignore the Monte Carlo data.  Now, thanks to Dan Flath, the Monte Carlo data is stored in a separate Root file.

Validation using muon_test
RootWriter has a test program that process a test-beam IRF file.  The output now consists of a "raw" root file and a "mc" root. file.
The first step in validation is to be sure that the raw root file created by the test program contains the same data that it did before we wrote out Monte Carlo data at all.  Here are plots of the hit strips in the TKR layers:
Original Version v4r1p0       New Version with MC v4r2
Looks Good!
If you are interested in viewing a full Root histogram file containing histograms generated with a Root macro called RawValidate.  The root files are located on the SLAC ftp site.  ftp://ftp-glast.slac.stanford.edu/glast.u04/RW/validate

New digiRootData Classes
The digiRootData Root classes have been updated for the 2001 Balloon Flight. 

Validation using muon_test
Again, we can use the muon_test program to begin our validation.  It is only 11 events - but it is a start.  Here are plots of the hit strips in first 16 TKR layers:
Original Version RW v4r2                   New Raw Root

Next, here are plots of the CAL ADC values for each of the four ranges:
Original Version RW v4r2                  New Raw Root

Next we can try a real ivte data file.

Validation using a BFEM IVTE data file
To start, a IVTE file created during one of the later SLAC BFEM testing runs was used.  The file is:
0990841437_0001.evt
It is available from the SLAC NFS and via FTP from ftp-glast.slac.stanford.edu/glast.u02/bfem/data
This IVTE file was converted to ROOT by both ROOTWriter v4r2 and the new version v5r2.

Both conversions find 9314 events in the IVTE file.
Here are some plots - note...no attempt is being made to make pretty plots of the data..we are only concerned about making sure that the same data are present in both files.
ACD/XGT:         v4r2              v5r2
CAL:                  v4r2               v5r2
TKR:                  v4r2               v5r2

But wait!  You say...  the ACD/XGT and TKR plots do not precisely match!  But... ah ha! That's right they don't!  And they're not supposed to!  Why?  Read on:

For the ACDs, 2 tiles ids have been swapped:  Id 001 and 011.  It was found that these tiles were connected to the opposite channel.. i.e. tile Id 001 is connected to channel 3 (when we thought it was 2) and tile Id 011 is connected to channel 2 (when we thought it was 3).  So we should see the plots of tiles 001 and 011 swapped - and we do.

For the XGTs, the identifiers have been modified.  Previously, we were following the numbering convention used during the instrument testing (XGT0, XGT1, XGT2, XGT3) - however, we are now using the Ritz ids (2000, 2001, 2010, 2011).  The Ritz ids do not map to the testing ids as one might expect.  Please see this document about the BFEM ids in the Root files.

The CAL plots are the same - and we would expect them to be.

For the TKR -a lot of work has gone towards organizing the TKR layers (where layer is defined as in the UCSC BFEM User's Guide - a single layer that measures X or Y) in the proper order.  For the testbeam, the TKR layers were not really sorted in order of their position in the TKR - now they are.  Hence - every other layer has been swapped from its position in the RW_v4r2 files - this is a GOOD things - really..I swear...Want some more proof?  Ok..well my good friend Leon ...  showed me that when plotting the TKR reconstruction for an event incident on the instrument at a steep angle in the event display used by bfemApp - one will actually see a zig zag pattern in the track - when the the X and Y layers have been swapped.  Here is an example.   Now...that the TKR layers are being sorted properly, things look good.  Here are some examples:
0994089668_0000_event8_view2.jpg
0994089668_0000_event8_view3.jpg
0994089668_0000_event33_view3.jpg

For more information about the identifiers used for the new digiRootData classes - please see this page.