add comment about why we assume that SNOMAN gets the PMT types right

1 files changed, 64 insertions, 1 deletions

diff --git a/src/zdab_utils.c b/src/zdab_utils.c
index de76172..e32a2f3 100644
--- a/src/zdab_utils.c
+++ b/src/zdab_utils.c
@@ -125,7 +125,70 @@ int get_event(zebraFile *f, event *ev, zebraBank *bev)
                 fprintf(stderr, "%i/%i/%i has PMT type %s but expected %s based on bank\n", crate, card, channel, pmt_type_string, pmt_names[i]);
             }
 
-            /* For now we assume SNOMAN has it correct. */
+            /* The above check prints out a warning on a handful of channels:
+             *
+             *     3/15/9 has PMT type NECK but expected OWL based on bank
+             *     18/0/14 has PMT type INVALID but expected BUTT based on bank
+             *     (+ a handful of other INVALID/BUTT discrepancies in crates 18 and 15)
+             *
+             * I sent an email to the SNO mailing list and Stan responded:
+             *
+             * > That PMT ID jogged a neuron somewhere, and I went hunting
+             * > through my email archive.  Here is an email I sent Neil 14 years
+             * > ago (?!) after we added the new neck tubes which might explain
+             * > how a neck tube ended up classified as an OWL.  When new neck
+             * > tubes were added for the NCD phase, they broke the range-based
+             * > logical PMT numbering:
+             *
+             * > On Tue, 9 Nov 2004 at 09:40:06 AM,  Neil wrote:
+             * > > Hi,
+             * > >
+             * > >     A new file has been released as should be in the database that has
+             * > > the updated neck tube positions. This file will also be in the new
+             * > > version of snoman to be released today or tomorrow.
+             * > >
+             * > >    Neil.
+             * > >
+             * > > Stan Seibert wrote:
+             * > > >
+             * > > > Hi Neil,
+             * > > >
+             * > > > I've noticed several issues in how neck tubes are handled in SNOMAN.
+             * > > >
+             * > > > * The 3 new tubes are plugged into channels 18/15/0, 18/15/10, and
+             * > > > 3/15/9.  According to map_ccc_tube.dat, the last two are tube numbers
+             * > > > 9635 and 9655.  The first, 18/15/0, currently has the entry -999999,
+             * > > > indicating it is a spare.  Is there a more up-to-date version of
+             * > > > map_ccc_tube.dat I should be looking at?  I tried reading through
+             * > > > Phil's pmt database for xsnoed, but was unable to find anything that
+             * > > > resembled tube numbers as SNOMAN defines them.
+             * > > >
+             * > > >
+             * > > > * Once that is corrected, I will need to fix ccc_type.for which
+             * > > > decides which PMT list (normal, owl, neck, etc.) each PMT hit goes
+             * > > > into.  This will uglify the function a bit because the neck tubes are
+             * > > > no longer in a contiguous block of tube numbers.  Numbers 9635 and
+             * > > > 9655 are actually in the OWL range.  How should backward compatibility
+             * > > > be handled here?  Do I hardcode a run number and check for it?
+             * > > >
+             * > > >
+             * > > > * With that fix, upk_unpacker_zdab_pmt.for will then file the neck
+             * > > > tube in its appropriate list, right?
+             * > > >
+             * > > >
+             * > > > Please let me know if this makes sense and where I can get updated
+             * > > > information.   Thanks.
+             * > > >
+             * > > > ---
+             * > > > Stan Seibert
+             *
+             * I also looked at the run in XSNOED and it looks like 3/15/9
+             * should be an OWL PMT and not a neck PMT.
+             *
+             * Based on the email and the fact that 3/15/9 *should* be an OWL
+             * PMT, I am going to assume that the database that SNOMAN uses to
+             * figure out the PMT types is correct and so reassign the PMT type
+             * based on that. */
             pmts[id].pmt_type = pmt_types[i];
 
             if (!b.next) break;