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 - 09:57:37 EDT