Hi Steve, Kris, et al, On Tue, 08 May 2001 10:56:46 -0500 hagel@comp.tamu.edu wrote concerning ": Re: Proposal to change BrSiRdo and BTileRdo - once again!": > BrDataObject had nothing to do (in my mind) with the fact that we were not > 100% committed to root. My feeling was that you introduced it back then. > It is a common BRAHMS data base class. Since TString stuff has been > fixed, we can migrate out of that and have it once again inherit > from TNamed if that is too much overhead, but not get rid of it. > I feel it gives us more if we have a common base class that we derive > all of our data classes in event nodes from. If we don't do that and need > some extra functionality, then we have to appeal to the root guys to put it > into TObject. Like what? We have nothing in BrDataObject that isn't already in somehow in TNamed. Anyway, we should not restrict ourselves unnessecarily to BrDataObject derived classes, and again that was not really the point. The point is, that BrTileChannelRdo, etc. are internal classes (heck, they could even by _nested_ for all I care, if that's possible in ROOT) to BrTileRdo, etc. That is, convinience classes. > On the tag in BrEventIO, I heartily agree. In fact I have done nearly the > equivalent of that when I imported BRAT stuff to use with NIMROD here at > TAMU. I had the advantage of hindsight when doing that. On the other hand, > it would seem to me a simple change in the streamer to implement that. I > have been thinking to do it, but as you know BrEventIO is such an important > class that I am afraid of touching it for breaking it. So I have not put > that tag class in. But with proper testing, it should be possible with no > loss of backward compatibility. No, it will not. The point of making such a tag class, would also be to change the class version of BrEventIO(Module) to 0 (ZERO), so that it cannot be written to disk - remember all that fuzz back then - thereby illimating the backward read compatibility. And again, this is not the only change that will do that, which we'd very much like to make, namely the use of ROOT 3 schema evolution. On Tue, 8 May 2001 11:01:47 -0500 "Sanders, Stephen J" <ssanders@ku.edu> wrote concerning ": FW: Proposal to change BrSiRdo and BTileRdo - once again!": > > 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? ^^^ ||| double quotes :-) This has nothing to do with pedestal substraction what so ever. The classes BrTileRdo and BrSiRdo are meant to store data after the first analysis pass (I think we can at least agree on that, right Flemming :-), that is in essence, energy signal and multiplicities. What might have confused you is the member fAdcChannelNo. What I mean by this is the hardware address (in the array) where the raw ADC value is put - _not_ the ADC value, which I probably would have called fAdc, fRawAdc, or event fAdcBin - and fCalibratedAdc is the _raw_ ADC value with the pedestal (and some times the width) subtracted. The later member is mostly present for your enjoyment. > > If so, is the idea that we would have a switch to turn off the > > pedestal threshold for calibration? No. Since RDOs will contain data after the first analysis pass, this has nothing to do with what you do for calibrations. (BRAHMS) <= TMA, SMA, ..., Hard-working people! | V -------- Raw Data <= BrTileDig, BrSiDig, ... -------- | V (RDO modules) <= BrTileRdoModule, BrSiRdoModule, ... | V -------- RDO data <= BrTileRdo, BrSiRdo, ... -------- | V (Physics analysis) <= MyFantasticModule, ... | V ------ Papers <= MyFantasticPlot.eps, MyFantasticPaper.tex, ... ------ | | V | (plain to Stockholm) | At | | Your V | Descretion ----------- | Nobel Prize | ----------- | What I'm suggesting what you could be able to turn off, was the storage of each individual tiles/strips and/or rings calibrated ADC, energy, hits, and multiplicity values, so that you'd only store the full arrays calibrated ADC, energy, hits, and multiplicity values. > > How do you see this implemented? For monitoring on-line, we want > > to see the pedestals. The raw ADC is stored in BrTileDig and BrSiDig objects, and online monitoring of pedestals etc. should inspect those objects, not the RDOs. It is the responsibility of BrRawDataInput to output those into a BrEventNode. The same thing goes for calibrations that need the raw ADC values, like pedestal finding, and similar. Calibration routines that work on energy signals could/should(?) look for RDOs. > > 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? Again, the raw ADC has nothing to do with RDOs since they are not stored there (just like TPC sequences are not stored in tracks). But, if you for example want to histogram the multiplicity of each tile, then you could do: TH2D* tileMultHist = new TH2D("tileMultHist", "tileMultHist", nTiles, -.5, nTiles + .5, 100, 0, 1000); BrTileRdoModule* tileModule = new BrTileRdoModule("TMA", "TMA"); ... while(moreEvents) { BrEvent* inev = new BrEvent("inev", 0, 0); BrEvent* outev = new BrEvent("outev", 0, 0); ... // Get the event data from some where tileModule->Event(inev, outev); BrTileRdo* rdo = (BrTileRdo*)outev->GetObject("MultTile"); TClonesArray& tiles = rdo->GetChannels(); TIter next(&tiles); BrTileChannelRdo* chRdo = 0; while((chRdo = (BrTileChannelRdo*)next())) tileMultHist->Fill(chRdo->fAdcChannelNo, chRdo->fMultiplicity); delete ev; } Incidently, if you had stored BrTileRdo on a TBranch of a TTree like: BrTileRdo* tmaRdo = 0; TTree* tree = new TTree("T", "T"); tree->Branch("tma", "BrTileRdo", &tmaRdo); ... while(moreEvents) { BrEvent* inev = new BrEvent("inev", 0, 0); BrEvent* outev = new BrEvent("outev", 0, 0); ... // Get the event data from some where tileModule->Event(inev, outev); tmaRdo = (BrTileRdo*)outev->GetObject("MultTile"); tree->Fill(); } you can later get the same histogram as above, by simply doing TH2D* tileMultHist = new TH2D("h", "tileMultHist", nTiles, -.5, nTiles + .5, 100, 0, 1000); tree->Draw("tma.fChannels.fAdcChannelNo:tma.fChannels.fMultiplicity>>h"); and you can even apply cuts like tree->Draw("tma.fChannels.fAdcChannelNo:tma.fChannels.fMultiplicity>>h", "tma.fArrayHits>0"); You can also quickly do a TEventList to only analyse (and read into memery!) a subset of events matching a certain criteria, rather than having to read through all events to find the interresting ones, and so on. This is technically not a feature of what I proposed, but it'd be much easier to do, if we decide to follow my suggestion. How you fill the TClonesArrays in BrTileRdo and BrSiRdo module would be more or less the same way as we do in BrTileRdoModule and BrSiRdoModule presently. I hope this clears up a few things. Otherwise, don't hesitate to write again. 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 - 13:52:47 EDT