diff options
Diffstat (limited to 'src/zdab_utils.c')
| -rw-r--r-- | src/zdab_utils.c | 65 |
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; |