Feature #1168
openGeneralize Detector Decode methods
12%
Description
Podd 1.7 currently has separate classes for detectors with FADC readouts and with legacy Fastbus modules. We should try to merge these separate classes into one by generalizing the detector Decode methods. This has already been started by implementing a generic Decode method in THaDetectorBase, but we still rely on different hardcoded setups of "DetectorData" objects in ReadDatabase of the detector classes. ("Fadc..." detectors create FADCData objects, while the corresponding legacy detectors instantiate PMTData or ADCData objects.) Ideally, the information about which "DetectorData" child class to use should come from the crate map, which is the authoritative source for the configuration of the frontend modules.
The current FADC decoding in Podd is quite limited. Lacking are- multi-hit decoding
- waveform retrieval
- waveform analysis
- reference times (extensively used by hcana)
Furthermore, Podd currently stores raw detector hit data in fixed-size arrays, whose size is that of the number of detector "elements" (paddles, mirrors, shower blocks, etc.) This was fine when detectors had a small number of elements, but it clearly wastes space with high channel counts. More importantly, it is also not really possible to accommodate multiple hits per channel with such arrays. We need to switch to parallel, variable-size arrays recording channel number and channel data, as it is done in SBS-offline.
At the same time, the design of the "detector map" of the detector classes should be revisited. The current design is too inflexible; it assumes a single type of frontend module for a given detector. It even duplicates the module number which is already present in the crate map. What if detector map and crate map disagree on the model number? I propose a "v2" detector map for the detector databases, with key "detector_map" instead of "detmap". THaDetMap should always retrieve the model number as well as other module information (module type, TDC resolution, etc.) from the crate map.
I'll add subtasks here to track the different aspects of this rather big job.