GSI Helmholtzzentrum für Schwerionenforschung
Hi, Does anybody know why this simple line in aliroot does not work? This is a part of AliTRDDigits2Raw.C root [0] AliTRDcalibDB* calibration = AliTRDcalibDB::Instance(); root [1] Int_t timeTotal = calibration->GetNumberOfTimeBins(); I-AliCDBManager::Init: AliEn classes enabled in Root. AliCDBGrid factory registered. E-AliCDBManager::Get: Run number neither specified in query nor set in AliCDBManager! Use AliCDBManager::SetRun. AliTRDcalibDB: Failed to get entry: TRD/Calib/Globals regards,
Hi Ken, I can not find this macro anymore in the TRD/Macros directory but to be able to use a AliTRDcalibDB, you have to be sure that the default storage is defined with its run number. So you have to put before: AliCDBManager *man = AliCDBManager::Instance(); man->SetDefaultStorage("local:://$ALICE_ROOT"); man->SetRunNumber(0); Then it should work. Regards, Raphaelle
Hi all, Thanks Raphaelle for your comments. Concerning raw data simulation, I am now moving my private test code and so on onto AliTRDrawData. Since I do not like to break Bogdan's preliminary raw data simulator implemented as Digits2Raw member, I change this method just as a switcher of the raw data simulator. So, now there are 3 more methods: virtual Bool_t SetRawVersion(Int_t v); virtual Bool_t Digits2RawV0(AliTRDdigitsManager* digitsManager); virtual Bool_t Digits2RawV1(AliTRDdigitsManager* digitsManager); and several internal parameters of this class. SetRawVersion will tell the class which version of raw data simulator should be used (currently 0 or 1). And Digits2RawV0 is the copy of Bogdan's implementation and it will stay without change. Digits2RawV1 is new one I'm implementing now. The version must be chosen in AliTRD by calling SetRawVersion. Default is still 0. The prototype declaration of Digits2Raw also changed: virtual Bool_t Digits2Raw(TTree *digits, TTree *tracks = NULL); Now it has tracklet information. Does anybody feel problem on this way of implementation? best regards,
Hi all, Concerning raw data simulation, I produced one date file with 18 DDLs data from TRD in and Christian tried to analyze this data using DATE. He fuond that baseline is not properly set and it is zero. In TRAP chip, normally ADC value itself has few ten to few hundred baseline, and it is changing acording to time by very low frequency time drift. This noise is filtered by digital filter (pedestal filter). ADC value should be unsigned integer of 10 bits dynamic range. If we subtract the baseline, we simply cut off all ADC values below the baseline. To avoid this problem, artificial baseline is again added after pedestal subtraction which is nominally 10 (but can be changed in TRAPsoftware). On the other hand in AliROOT, additional baseline is not added. Baseline is simply subtracted and negative value is simply cut. This is of course not good because noise appeared only on positive ADC value. Effetively we change the baseilne little bit above if we define the baseline as average signal. I think we must do like TRAP is doing which is: Define some ADC intrinsic baseline (define randomly). Apply baseline subtraction as TRAP is doing. Add artificial baseline (10, as TRAP is doint). Then digits value will fluctuate around 10, and it presents even negative value (below 10) and cross talk as well. I think this gives impact to reconstruction part. Somone has to change reconstruction part to take into account the baseline which is not ADC intrinsic baseline but artificial baseline added by TRAp. How do you think? best regards, Ken Oyama
Hi Ken and all, my feeling was always that simply setting a baseline of 10 or some other value in AliRoot would be sufficient. That is how I always did in my simulations of position reconstruction performance. I do not see a need to simulate all steps that the TRAP does here, because the outcome is simply a baseline of 10. Do you expect any effect of the pedestal filter (baseline restoration algorithm in the TRAP chip) on the performance of the tracking? But of course it is possible to do like you propose. Best regards, Christian
Hi Christian, and all, Adding TRAP pedestal of 10 might be enough if we do it carefully. What will be different from real case is that if ADC intrinsic pedestal is large (like 100), we loose dynamic range of 10 % because ADC range is limited from 0 to 1023. This feature can not be simulated if we add 10. It seems designer of current digitizer was thinking about this effect as far as I see from the code. This problem is relevant only if there is huge signal. I do not know this affects to tracking performance. Maybe it is negligible. Does anybody know? If we decide such effect is negligible and do not care then I would just put 10 (actually it was done!). best regards, Ken
Hi Ken, The effect on tracking will be negligible (I think). But on PID there might be an influence. Anton and Alex B. might know better ... Ciao, Christian