CalDigi contains information about the raw data from the calorimeter. It is intended to be filled from any of our data sources (MC or real data sources) to present a uniform interface to CalRecon.
The file actually contains two classes:
CalLogReadout: an ADC reading and an ADC range for each end of the log.
CalDigi: LogId, Trigger mode, and a vector of CalLogReadout's
I we discourage having more than one class in a file. It's convenient for includes but it makes it harder to find the secondary classes.
All the information is there. Members are set in the constructor, and there are access methods called "getXxx" (What should we be calling the access methods?) and standard streamers.
CalLogReadout inherits from the Gaudi ContainedObject, but I don't think it needs to, as it is not contained in a Gaudi Container.
The ADC value is stored in a short, and the range in a char, to save space. This, particularly the latter, seems to me to increase turbidity. Probably not much point for the relatively small number of logs. The PDS is compessed anyway.
Again, everything seems to be there. There are "setXxx" and "getXxx" methods, and streamers. Two containers are defined, CalDigiVector and CalDigiList.
According to our conventions, the container should be called CalDigiCol.
The members are set through "setXxx" methods, which is deprecated.
The enum AcdRange {LEX8, LEX1, HEX8, HEX1} is different from what is in CalBase ( LEX, LE, HEX, HE).
The enum LogFace {POS, NEG} is backwards from what is in CalBase ( NEG, POS).
The masks 0x3000 and 0xfff are defined in an enum. Would it be more natural to make them const static integers?
L. Rochester Last Modified: 2002-04-04 13:45:06 -0800