|
|
| Re: Raw data read and write [message #3803 is a reply to message #3802] |
Wed, 29 November 2006 18:03   |
Ken Oyama
Messages: 7
Registered: November 2006
Location: Heidelberg
|
occasional visitor |
From: *physi.uni-heidelberg.de
|
|
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,
Ken
|
|
|
|
| Re: Raw data read and write [message #3805 is a reply to message #3803] |
Thu, 30 November 2006 09:40 |
Raphaelle Bailhache
Messages: 14
Registered: July 2006
|
occasional visitor |
From: lxial32.gsi.de
|
|
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
|
|
|
|
| Re: Raw data read and write [message #3807 is a reply to message #3802] |
Thu, 30 November 2006 15:32 |
Ken Oyama
Messages: 7
Registered: November 2006
Location: Heidelberg
|
occasional visitor |
From: *physi.uni-heidelberg.de
|
|
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,
Ken
|
|
|
|
| Re: Raw data read and write [message #3839 is a reply to message #3802] |
Wed, 06 December 2006 10:47 |
Ken Oyama
Messages: 7
Registered: November 2006
Location: Heidelberg
|
occasional visitor |
From: *physi.uni-heidelberg.de
|
|
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
Ken
|
|
|
|
| Re: Raw data read and write [message #3840 is a reply to message #3839] |
Wed, 06 December 2006 11:02 |
Christian Lippmann
Messages: 4
Registered: March 2004
Location: GSI
|
occasional visitor |
From: pcceres32.cern.ch
|
|
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
-------------------------------------
Christian Lippmann
Gesellschaft für Schwerionenforschung
Planckstr. 1
D-64291 Darmstadt
phone: +49-6159 71 1341
http://www-linux.gsi.de/~lippmann
-------------------------------------
|
|
|
|
| Re: Raw data read and write [message #3846 is a reply to message #3840] |
Wed, 06 December 2006 18:17 |
Ken Oyama
Messages: 7
Registered: November 2006
Location: Heidelberg
|
occasional visitor |
From: *physi.uni-heidelberg.de
|
|
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
Ken
|
|
|
|
| Re: Raw data read and write [message #3847 is a reply to message #3846] |
Wed, 06 December 2006 18:40 |
Christian Lippmann
Messages: 4
Registered: March 2004
Location: GSI
|
occasional visitor |
From: pb-d-128-141-39-182.cern.ch
|
|
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
-------------------------------------
Christian Lippmann
Gesellschaft für Schwerionenforschung
Planckstr. 1
D-64291 Darmstadt
phone: +49-6159 71 1341
http://www-linux.gsi.de/~lippmann
-------------------------------------
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
