Hi Trine et al, On Thu, 28 Jun 2001 20:11:25 +0200 (MET DST) trine@lynx.uio.no (Trine Tveter) wrote concerning ": RE: Some numbers from Norway": > Hi Christian et al., > > On Thu, 28 Jun 2001, Christian Holm Christensen wrote: > > > My feeling is, that you are using some BRAT version or similar where > > there's an error. Please compare the BRAT code you're using to the > > current code. What version of BRAT is it you're using? What version > > of ROOT? > > This is definitely my feeling too ;-) - it was probably hard to > extract this from the long selection of previous messages, but the > problem is in short that we're trying to read a .root sequential > file made with an April BRAT version (probably April 2 - I'm not > sure if Bjørn had migrated to ROOT 3.00 then or not) with one of > the latest versions of BRAT (June 18 / June 19) and ROOT 3.00. > The number BR_SI_CHAN_MAX has changed from 224 to 288 in the meantime. > We're getting streamer errors on BrRdoZDC and BrSiDig: > > Error in <TBuffer::CheckByteCount>: object of class BrRdoZDC read too few bytes > Warning in <TBuffer::CheckByteCount>: BrRdoZDC::Streamer() not in sync with data on file, fix Streamer() > Error in <TBuffer::CheckByteCount>: object of class BrSiDig read too many bytes > Warning in <TBuffer::CheckByteCount>: BrSiDig::Streamer() not in sync with data on file, fix Streamer() I think the problem lies in the above message on BrRdoZDC. Suppose the file looked like |--- BrRdoZDC -----|-------- BrSiDig -------|-- ..... where a '-' marks a word (4 bytes = sizeof(int)) but when you read it, you read |--- BrRdoZDC ---|---------- BrSiDig ----------|-- ..... that is, the first 2 word of BrSiDig actually comes from BrRdoZDC and not BrSiDig, and this may be the root (no pun intended) of the problem. Try turning on debug mode in ROOT, by setting Root.Debug: 4 in your ~/.rootrc. That may give you a clue. A diff on BrRdoZDC from April 2 to 1.16.6, gave 24,27c26,107 < private: < < Float_t a1L, a2L, a3L, aL, a1R, a2R, a3R, aR, t1L, t2L, t3L, tL, t1R, t2R, t3R, tR; < BrVertex ZDCVtx; --- > private: > Float_t a1L, a2L, a3L, aL, a1R, a2R, a3R, aR, t1L, t2L, t3L, > tL, t1R, t2R, t3R, tR; > Float_t energyL, energyR; > Float_t time1L, time2L, time3L, timeL, time1R, time2R, time3R, > timeR; > BrVertex ZDCVtx; > > i.e., the old BrRdoZDC is infact 40 bytes! (4 bytes / Float_t * 10 Float_t's) longer the old BrRdoZDC. And what ofcourse is really REALLY bad, is that the Class version wasn't incremented. This was done late april: // $Log: BrRdoZDC.h,v $ // Revision 1.7 2001/04/24 02:54:00 makeev_a // Slewing correction has been refined for all 6 ZDC modules, Reconstructed Data Object returns calibrated energy, times and vertex I have no idea who the user "makeev_a" is, so I don't know who to flame for this. > and are trying to repair manually. I don't think that's a good idea. This is because it's practically imposible to know if what you read back from the file is infact the right numbers. My suggestion is to redo the reconstruction pass using a newer ROOT or at least the same as the one you use for analysis. The last version of BRAT1 (our production version) is in pretty good shape. If you have trouble getting it, I can make a tar-ball avaliable to you. Let me know. > For the Si data the first two entries are (printed with BrDigSi::List()) > > ID # 0 ADC: 0 > ID # 1 ADC: 224 (same for all events - must be fNumSiChan) > > and then they behave just like you describe below, just with an > index shift of 2: > ... More numbers > ID # 97 ADC: 209 > ID # 98 ADC: 0 > ... More zeroes > ID # 113 ADC: 0 > ID # 114 ADC: 88 > ... More numbers > > > I just did a similar test with BRAT 2.0.0. I read 10 events of > > sequence 000 or run 2535, and they showed (never mind the actual ADC > > values, they were different from event to event - ofcourse): > > > SMA Digits: > > DigSi Raw > > ID # 0 ADC: 131 > > ID # 1 ADC: 159 > > ... More numbers > > ID # 95 ADC: 211 > > ID # 96 ADC: 0 > > ... More zeroes > > ID # 111 ADC: 0 > > ID # 112 ADC: 34 > > ... More numbers > > ID # 223 ADC: 17 > > ID # 224 ADC: 0 > > ... More zeroes > > ID # 287 ADC: 0 > > If I perform an index shift of 2 and initialize manually the elements > from 224 to 287, the histograms at least look sensible :-). If the > same ID#'s or locations have been referring to the same physical Si > elements all the way, from April to June, I think this repair should > be OK (though I have no idea how the index shift came about from a > presumable bitwise copy ...) I tested the bitwise copy thing with the BRAT from April 2 (1.15.1), and that turned out not to be the problem. Here's my test: #include <iostream> #include <iomanip> #include <BrSiDig.h> void foo() { BrSiDig* s1 = new BrSiDig("s1", "s1"); for (Int_t i = 1; i <= 224; i++) s1->SetAdc(i, i); BrSiDig* s2 = new BrSiDig(*s1); cout << " Old | New " << endl << "----------+-----------" << endl; for (Int_t i = 1; i <= 224; i++) cout << " " << setw(8) << s1->GetAdc(i) << " | " << setw(8) << s2->GetAdc(i) << endl; cout << endl; } Do root [0] .x foo.C++ > About the Tile data, where there's no evidence of a shift: > > > (does this look healthy to an expert?) > > Well, almost. The reason why channel 43 -> 48 is zero, is simple > > because there's no such tiles in the IR at the moment, but there's in > > principle room for them. Channel 23 and 24 (channel 22 and 23 in > > BrTileCalibration lingo) should be ignored, since they are not > > instrumented either (at least since some date I can't remember when - > > Steve and Hiro knows). > I guess the RdoModules know what elements to ignore .... Yeps it does. [Rest of mail is for the paper commitee, and deleted here] 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 2b30 : Thu Jun 28 2001 - 15:56:22 EDT