Hi Christian et al., I don't see a problem with the new scheme. Your example pretty much tells me what I need to know for changing my own programs, and it doesn't look like it will take much effort. I don't fully follow the discussion between you and Kris, but I don't have any objections to the changes that you propose. You might also want to take this opportunity to remove the BrRdoMultModule. The module will no longer work and, from my perspective, it has served its purpose of allowing me to familiarize myself with and to check the output of the new mult classes. I believe Bjorn is the only person to indicate that they ever used this module and, from his last note, it looks like he has also migrated to the new classes (Bjorn--or anyone else-- correct me if I'm wrong!). ...steve > ---------- > From: Christian Holm Christensen > Reply To: brahms-dev-l@bnl.gov > Sent: Tuesday, May 8, 2001 12:51 PM > To: brahms-dev-l@bnl.gov; ssanders%ku.edu.hagel@comp.tamu.edu > Subject: Re: FW: Proposal to change BrSiRdo and BTileRdo - once > again! > > 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 - 14:21:45 EDT