Hi all, This is - I'm afraid - a rather long mail. It's only really interresting to people doing some stuff with the SMA and TMA, but I sent it to the list in the spirit of openess and for achiving purposes. On Wed, 27 Jun 2001 12:01:41 -0500 "Sanders, Stephen J" <ssanders@ku.edu> wrote concerning ": RE: Some numbers from Norway": > Hi Trine, > I've added Christian to the distribution list since on this topic he is > "THE" expert on the mult class changes. I send this message to brahms-dev-l as well, since it's nice to archive such communication somewhere accesible to all. If brahms-dev-l is the wrong list, I beg your pardon, and could you please advice as to which list it should go to. > From your solution, and also from what I see looking at the code, > I'm starting to think the problem is in how the root file was > created, and not any changes that have occurred with the code. The > ADC values and local storage are offset by 1, and so it looks as if this > offset might have been mishandled. What do you mean "offset by one"? Are you refering to the index into the array or are you refering the actual ADC value? > If so, it is likely that a similar problem will exist with the tile > data. As far as I can tell, the Dig classes basically do the same > thing as before and the change in indexing that I referred to in my > message has more to do with the local organization. The Br[Tile|Si]Dig is classes has not changed, except for the size of the internal array contain the ADC and temperature signals from the SMA. The index into the array is the ADC channel number (the module - not value), as defined by the DAQ event builder. > The strange results for locations 225 to 289 looks like an > initialization (or lack thereof) error. Yeps, that looks like a problem pertaining to lack of initialisation. This problem pop-up all the time, ever since we started using ROOT 3.00/05, where data isn't automatically initialised, since we do not link against libNew. I'll add the initialisation of the internal array of classes Br[Tile|Si]Dig right away. Uh, I don't know who did it, but in BrSiDig there's the line BrSiDig(){ }; The ';' at the end is not needed and is misleading. It should read BrSiDig(){ } I've seen this in quite a lot of places in the code. If you know of any such code, please correct it. > Hi Christian, I've added some of the ealier notes at the end of > this. The basic problem is that Trine and Bjorn are trying to redo > the TPM1 analysis using the common centrality module. In their > first run through, they obtained results which contradicted the Si > and Tile results. I'm not sure I understand where and how this contradiction came about. Is it a difference in BRAT (1) version that did it, or was it the use of change from BrMultCentModule that made the difference? > This is when Bjorn skipped town.... In looking at > their results in more detail, Trine noticed an inconsistency with > the Si multiplicity. I've attached the notes transferred since > then. Am I correct in claiming the the Dig behavior is the same as > before? In so far as you disregard the libNew issue, yes. > Do you have any additional thoughts on the problem? This is our main > holdup in producing a final draft for the multiplicity paper so we > are obviously very anxious to have this resolved quickly. Thanks. > Steve I'm a bit puzzled as to why you want to now about the BrSiDig stuff, since BrSiRdoModule and so on does the right thing, and so you should really only care about the BrMultRdo objects. Ofcourse if you're creating a calibration module (hint hint), you need to know the format. On another issue: Have you given it some thought about what I wrote on doing centrality cuts in the total deposited energy in SMA and TMA instead of the multiplicity. In that way, we're not dependent on the energy-to-multiplicity calibrations, particular outlier methods, and so on. The only thing we then need to have to do the centrality calibrations are: Pedestal Gap (TMA only) Pulser (SMA only) Gain Geometry (Vertex dependent path length correction) What do you think. I spoke with the group here at NBI, and there was a general consensous that this would be a good idea. Please reply soon, as this should be done before the new run period starts. > > ---------- > > From: trine@lynx.uio.no > > Sent: Wednesday, June 27, 2001 5:28 AM > > To: ssanders@KU.EDU; burton.budick@nyu.edu; videbaek@sgs1.hirg.bnl.gov; > > Fouad.Rami@IReS.in2p3.fr; hito@students.phsx.ukans.edu; jhlee@bnl.gov; > > gardhoje@nbi.dk; yklee@jhu.edu; Yury_b@physics.nyu.edu > > Cc: trine@lynx.uio.no; b.h.samset@fys.uio.no > > Subject: RE: Some numbers from Norway > > > > ---------- > > X-Sun-Data-Type: text > > X-Sun-Data-Description: text > > X-Sun-Data-Name: text > > X-Sun-Charset: us-ascii > > X-Sun-Content-Lines: 46 > > > > Hi Steve et al., > > > > On Tue, 26 Jun 2001, Steve Sanders wrote: > > > > > Hi Trine, I'm afraid you are correct. When the mult classes were > > > reorganized, the mappings were changed. Christian wanted to do > > > this to obtain a format that would be easier to handle with the > > > database. The mapping is done via Br[Tile|Si]Calibration (actually Br[Tile|Si]TmpCalibration for now, since no cliabration database is up and running yet), and the methods: Short_t Br[Tile|Si]Calibration::GetRingMap(Int_t tileNo) const Short_t Br[Tile|Si]Calibration::GetRowMap(Int_t tileNo) const The argument to these methods is zero-bassed, so you need to do: // Calibration BrSiTmpCalibration* calibration = BrSiTmpCalibration::Instance(); // Detector parameters TString tableName(BrDetectorList::GetDetectorName(kBrSi)); BrParameterDbManager* paramManager = parameters = (BrSiParameters*)BrParameterDbManager::Instance() ->GetDetectorParameters("BrSiParameters", tableName.Data()); // Raw data tableName.Prepend("Dig"); BrSiDig* siDig = (BrSiDig*)inNode->GetObject(tableName.Data()); nSi = parameters->GetNoModules(); for (Int_t i = 0; i < nSi; i++) { Int_t ringNo = calibration->GetRingMap(i); Int_t rowNo = calibration->GetRowMap(i); Short_t adc = siDig->GetAdc(i + 1); // Do what ever. } See also Br[Tile|Si]RdoModule. Maybe we should have the inverse mapping in Br[Tile|Si]Calibration as well: Short_t BrSiCalibration::GetAdcMap(Short_t ring , Short_t row) { if (!fRowMap.fAccessMode && fRowMap.fRevision) return -1; if (!fRingMap.fAccessMode && fRingMap.fRevision) return -1; Short_t* rowMap = (Short_t*)fRowMap.fRevision->GetArray(); Short_t* ringMap = (Short_t*)fRingMap.fRevision->GetArray(); Int_t n = TMath::Max(fRingMap.fRevision->GetEntries(), fRowMap.fRevision->GetEntries()); for (Int_t i = 0; i < n; i++) { if (rowMap[i] == row && ringMap[i] == row) return i; } return 0; } We could also rework the map, so that the 16 upper bits [0,255] maps the ring, and the 16 lower bits maps the row: Short_t GetAdcMap(Short_t row, Short_t ring) { if (!fAdcMap.fAccessMode && fAdcMap.fRevision) return -1; UShort_t* adcMap = (UShort_t*)fAdcMap.fRevision->GetArray(); Int_t n = fAdcMap.fRevision->GetEntries(); UShor_t_t map = (row << 8 | ring); for (Int_t i = 0; i < n; i++) if (adcMap[i] == map) return i; return -1; } Short_t GetRowMap(Short_t adcNo) { if (!fAdcMap.fAccessMode && fAdcMap.fRevision) return -1; return ((UShort_t)(fAdcMap.fRevision->GetArray())[i] >> 8); } Short_t GetRingMap(Short_t adcNo) { if (!fAdcMap.fAccessMode && fAdcMap.fRevision) return -1; return ((UShort_t)(fAdcMap.fRevision->GetArray())[i] & 0xff); } This would actually save quite a lot of storage space in the database, however at the cost of clarity. > > > I developed a mapping going from the "new" to the > > > "old" so that I could continue to use my programs, but since I > > > have been replaying from the "raw" data files, I have never > > > needed to map from the "old" to the "new". I think it should > > > be relatively easy to devise a program to do the mapping that > > > you need, but I need to look a little more at the code. > > > > I have tried remapping the data in a simple and intuitive way, > > just copying the 224 "sensible" entries into a new BrSiDig object > > in the sequence they appeared, to see what came out of it. This approach will certainly make Br[Si|Tile]RdoModule fail! > > I used the following lines of code: > > > > BrSiDig* SiTable = (BrSiDig*)event->GetObject("DigSi"); > > // SiTable->List(); > > BrSiDig* NewSiTable = new BrSiDig("DigSi","DigSi"); > > for (Int_t isi=1; isi<289; isi++){ > > if (isi<225) NewSiTable->SetAdc(isi,SiTable->GetAdc(isi+2)); ^^^^^ ||||| This seems odd. The first ADC value should be stored in BrSiDig::fAdc[0], _not_ BrSiDig::fAdc[1] > > if (isi>=225) NewSiTable->SetAdc(isi,0); > > } > > // NewSiTable->List(); > > RawNode->AddObject(NewSiTable); > > SiTable->SetName("OldDigSi"); > > > > I have attached 2 plots where I looked at the same 5000 events > > from run 2530, one without and one with this remapping. It looks > > promising - if an expert can verify the remapping, I can try to > > generate trees again from the sequential root files. > > > > The BrRdoZDC retrieved from the old .root files is also sick (for the > > moment, the GetZ() always gives zero) but since the BB vtx is > > present and healthy this should not have any impact on the > > analysis. I don't know why this happens though. Seems like an old solved problem, but I may be wrong. > > > > Best regards, > > Trine > > > > > > Hi Steve, > > > > On Tue, 26 Jun 2001, Steve Sanders wrote: > > > > > Last night I replayed run 2530. The .gif file is attached. > > > I don't see any evidence for the type of Si shift that you find. > > > My guess is that you are not properly passing the run number to > > > the get calibration programs: > > > > > > if(runno>0) fTileCalibration->ReadASCIIFile(runno); > > > > > > and, similarly, for the si detectors. This would have the > > > consequence of bringing in a very early, and very incorrect, > > > "default" calibration. You can check this by setting the > > > DebugLevel for BrSiCalibration > 5. This will result in the > > > program printing out the run number used for the calibration. > > > If the run number is less than 1761 (including zero) the program > > > will use a calibration developed for the early tests, before the > > > array was fully implemented. > > > > I fear that the problem is not as simple as that - I tried what > > you suggested above, and the module clearly said that it was > > reading the calibration file for run 2530 as intended. > > > > We keep getting streamer errors on BrRdoZDC and BrSiDig - the > > .root file was produced with an April version of Brat, and since > > then some extra data members have been added in BrRdoZDC and the > > array in BrSiDig has been expanded from 224 (?) to 288. I've > > tried to print out the data in the Si array from 0 through 287 - > > they start with: > > > > Si number: 0 ADC: 0 > > Si number: 1 ADC: 0 > > Si number: 2 ADC: 224 How did you print this? In BRAT now, is the method BrSiDig::Print() > > and then comes a sensible-looking list of numbers up to 227, with > > a series of zeros from 99 to 114. From 227 and up they start > > going weird ... if the SiRdoModules interpret them as Si ADC > > values, this may well give rise to some really crazy results. > > > > Si number: 227 ADC: 16384 > > Si number: 228 ADC: 244 > > Si number: 229 ADC: -1 > > Si number: 230 ADC: -1 > > Si number: 231 ADC: 17010 > > Si number: 232 ADC: 17513 > > Si number: 233 ADC: 26458 > > Si number: 234 ADC: 17475 > > Si number: 235 ADC: 0 > > Si number: 236 ADC: 256 > > Si number: 237 ADC: 256 > > Si number: 238 ADC: 256 > > Si number: 239 ADC: 0 > > Si number: 240 ADC: 3 > > Si number: 241 ADC: 0 > > Si number: 242 ADC: 1 > > Si number: 243 ADC: 0 > > Si number: 244 ADC: 64 > > Si number: 245 ADC: 17513 > > > > ... and so on. > > > > The .root files we've been trying to read are located on: 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 > > > > /brahms/data02/scratch/bjornhs/BSMRS_*****_reco_NTFF.root > > > > (from April) if you want to have a look for yourself (and try to > > run a histogram on one of those to see if the effect is > > reproduced.) The typical event contents of the .root files are: > > > > 0 - 0x92d0b60 - Tracking Node - reco > > 0 - 0x92cbd08 - DetectorTrack TPM1 - DetectorTrack TPM1 > > 1 - 0x92cbf88 - Vertex Node - reco > > 0 - 0x92b38a0 - BB - Rdo data > > 1 - 0x92ae218 - RdoZDC - RDO data > > 2 - 0x929c6c0 - TPM1 Cluster VtxData - TPM1 Cluster Vertex Data Object > > 3 - 0x92c3500 - TPM1 Track VtxData - TPM1 Track Vertex Data Object > > 2 - 0x929e418 - Raw Node - select > > 0 - 0x92ae6f0 - DigTof TOFW - DigTof TOFW > > 1 - 0x92ae868 - DigTiles - Raw > > 2 - 0x929f918 - DigSi - Raw > > 3 - 0x929fc10 - DigZDC - raw > > 4 - 0x929fcf8 - DigZDCLo - raw > > 3 - 0x929fdf0 - TPM1 NClusters - TPM1 NClusters > > 4 - 0x929fea8 - TPM1 TFF Status - TPM1 TFF Status > > > > If this is the cause of our problem, I think the data could still > > be salvaged if one copied the correct entries in the correct > > sequence into a fresh BrSiDig object - I think this would be a lot > > faster than redoing the whole analysis with tracking and all. > > Here we need input from experts on the ring mapping (and with > > experience with the April version of the data objects - how should > > the old array of 224 entries be mapped into the new one, with 288 > > entries?) > > > > What do you think? I'm giving up for the day, but will try to continue > > looking into this tomorrow with some help from the experts ... > > > > Best regards, > > Trine 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 - 10:52:09 EDT