> Hi Christian, > > I need some information before I can make reasonable comments on this > proposal: > Am I correct in believing that this proposal only saves space if we do > pedestal subtraction in software? If so, is the idea that we would have > a switch to turn off the pedestal threshold for calibration? How do you > see this implemented? For monitoring on-line, we want to see the > pedestals. > Also, could you provide a code example of how one would > loop over the tile elements, for example, to extract the raw adc channel > and calibrated energy information? > > ...steve > ---------- > From: Christian Holm Christensen > Reply To: brahms-dev-l@bnl.gov > Sent: Tuesday, May 8, 2001 8:56 AM > To: brahms-dev-l@bnl.gov > Subject: Proposal to change BrSiRdo and BTileRdo - once again! > > Hi BRATs, > > Ok. Once again I risk my neck and propose the change to the classes > > BrTileRdo > BrSiRdo > > that will make it hard (impossible?) to read old files with the old > implementation. > > The reason for this change, is that I found out that the BrSiRdo > objects are way too big (4744 bytes!), which proves to be a problem if > you want more than 5x10^5 events in one file (you hit the 2GB file > limit, even without tracks!). Also such big objects are not very > efficient. > > The best way to solve this problem, I believe is to introduce 4 > utility classes (2 for SMA and 2 for TMA): > > class BrTileChanRdo : public TObject { > public: > UShort_t fAdcChannelNo; // Channel number > Float_t fCalibratedAdc; // > Float_t fEnergy; // > Float_t fMultiplicity; // > Bool_t fIsSaturated; // > > BrTileChanRdo() > : fAdcChannelNo(0), fCalibratedAdc(0), fEnergy(0), > fMultiplicity(0), fIsSaturated(0) {} > > BrTileChanRdo(UShort_t chan, > Float_t calAdc, > Float_t energy, > Float_t mult, > Bool_t saturated=kFALSE) > : fAdcChannelNo(chan), fCalibratedAdc(calAdc), fEnergy(energy), > fMultiplicity(mult), fIsSaturated(satureated) { > IsA()->IgnoreTObjectStreamer(); > } > > Int_t Compare(TObject& o) const { > return (fAdcChannelNo < ((BrTileRingRdo)o).fAdcChannelNo ? -1 : > (fAdcChannelNo > ((BrTileRingRdo)o).fAdcChannelNo ? 1 : 0)); > } > ClassDef(BrTileChanRdo,1) // Single tile RDO class > }; > > > class BrTileRingRdo : public TObject { > public: > UShort_t fRingNo; // Channel number > Float_t fCalibratedAdc; // > Float_t fEnergy; // > Float_t fMultiplicity; // > UShort_t fHits; // > Float_t fEta; // > > BrTileRingRdo() : fRingNo(0), fCalibratedAdc(0), fEnergy(0), > fMultiplicity(0), fHits(0), fEta(0) {} > > BrTileRingRdo(UShort_t ring, > Float_t calAdc, > Float_t energy, > Float_t mult, > UShort_t hist, > Float_t eta) > : fRingNo(chan), fCalibratedAdc(calAdc), fEnergy(energy), > fMultiplicity(mult), fHits(hits), fEta(eta) { > IsA()->IgnoreTObjectStreamer(); > } > > Int_t Compare(TObject& o) const { > return (fRingNo < ((BrTileRingRdo)o).fRingNo ? -1 : > (fRingNo > ((BrTileRingRdo)o).fRingNo ? 1 : 0)); } > ClassDef(BrTileRingRdo,1) // Tile ring RDO class > }; > > These will then be stored in TClonesArray members of BrTileRdo: > > class BrTileRdo : public BrDataObject { > private: > UInt_t fNChannels; //! Cache variable > TClonesArray fChannels; > UInt_t fNRings; //! Cache variable > TClonesArray fRings; > > Float_t fArrayCalibratedAdc;// Array sum calibrated ADC > Float_t fArrayEnergy; // Array sum deposited energy > Float_t fArrayMultiplicity; // Array sum multiplicity > Int_t fArrayHits; // # of tiles above threshold > public: > BrTileRdo(const char* name, const char* title) > : BrDataObject(name, title), > fNChannels(0), fChannels("BrTileChannelRdo", 0), > fNRings(0), fRings("BrTileRingRdo", 0) {} > > AddChannelRdo(UShort_t chan, > Float_t calAdc, > Float_t energy, > Float_t mult, > Bool_t saturated=kFALSE) { > new(fChannels[fNChannels++]) BrTileChannelRdo(chan, calAdc, > energy, mult, > saturated); > } > > AddRingRdo(UShort_t chan, > Float_t calAdc, > Float_t energy, > Float_t mult, > UInt_t hits, > Float_t eta) { > new(fRings[fNRings++]) BrTileRingRdo(ring, calAdc, > energy, mult, > hits, eta); > } > > Float_t GetChannelMult(int channel) { > if (!fChannels[channel]) > return 0; > return ((BrTileChannelRdo*)fChannels[channel])->fMult; > } > ... > } > > and similar for the SMA. > > This will ofcourse affect a number of classes in the mult directory, > and possible also at a few other places, and I will ofcourse propegate > the changes should we be in agreement. > > In fact, I believe this has many advantage over the old > implementation. Certainly it will be much easier to read through a > TTree containing these modified BrTileRdo and BrSiRdo, due to the use > of TClonesArray, and simple objects. Also, we will only ever need to > store data for those channels/rings that actually have data. > > We could also have a flag, so that one may choose wether to store > individual tile/strip and/or ring data, thereby really cutting down > the size. The reason we'd like to keep the individual detector data, > is that it's usefull for a number of analysis, but not nessecarily > all. > > The reason I don't want to use BrClonesArray, is simply that is the > same as TClonesArray and should disappear soon. > > The reason I don't use BrDataTable is that it's not well suited for > TTree's and there's additional overhead, and anyway I don't need a > name and title for the arrays, since BrTileRdo and BrSiRdo already has > a name via BrDataObject. > > The reason I don't use STL containers is that they are too slow for > iteration in a TTree. > > I think this chance should be imbrassed now that a multiplicity paper > is to be written, since presumabmly you'll need loads of data for > that. > > Upcoming BRAT2 will definitly break backward compatiblity for reading > old files. I think a month(?) is a reasonable time scale for BRAT2, > so you should start commiting your stuff to BRAT1 now, since BRAT1 > will soon be frozen (you'll recive due notice, but take this as a > warning). > > We could also take this as step towards a IMHO, better way of storing > event data than BrEventNodes, that is in TTrees that you can fairly > easy investigate using the new GUI. The development in ROOT 3 in this > area is overwhelming and very promising. Kris seems to have a similar > idea (see ana/inc/BrPhDSEvent.h). BTW Kris, could you remind me what > PhD stands for? > > If I don't hear huge outcries and serious complaints within this week, > I'll make the above changes next week. > > Yours, > > Christian ----------------------------------------------------------- > Holm Christensen Phone: (+45) 35 35 96 91 > Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 > DK-2200 Copenhagen N Web: www.nbi.dk/~cholm > Denmark Email: cholm@nbi.dk > > >
This archive was generated by hypermail 2b29 : Tue May 08 2001 - 12:02:35 EDT