Christian,
You indeed risk your neck!!!
Why can the streamer not be simply changed to write only relevant data? As far
as I can tell, that would accomplish what you want to accomplish regarding disk
space and it would keep backward compatibility. On the issue of backward
compatibility with brat_v2, I do not yet see why it is going to break assuming I
get my way and we don't change names of classes. I admittedly have not read
everything, but I have been using brat_v2 since the beginning of the year with
root_v3 and I am reading everything I have tried and it works.
I agree with not using BrClonesArray. (even though I wrote it!!!)
Will the fact that they not inherit from BrDataObject not break other things and
break BRAT programming specifications?
I consider this a huge outcry, but would like to hear what the mult people have
to say.
Kris
Christian Holm Christensen wrote:
> 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 - 10:26:42 EDT