ALICE Calibration Requirements |
|
|
|
|
FMD OK July 06 |
Completed by: Christian Holm Christensen
<cholm@nbi.dk>, modified 2006-09-04 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Par # |
Parameter |
Data format/size
per channel |
Data size (Total)
Bytes |
Update freq |
Source |
Confirmed |
Run type / Trigger type |
# of required
events/sampling rate |
Processing level:
sub-event or event |
Results:
FEE/Archive |
Accessible
by offline |
Calib. Procedure in AliRoot |
use case # |
|
|
|
in FES |
in OCDB |
reference |
|
|
|
|
|
|
|
|
|
|
1 |
Oversampling rate |
4 Bytes/half ring |
|
40 |
0 |
< Run |
DCS or Event(2) |
yes (2,3) |
all triggers (4) |
- |
- |
DCS
ArchiveDB/OCDB |
yes! |
- |
4 |
2 |
Strips readout |
2 Bytes/half ring |
|
20 |
0 |
< Run |
DCS or Event(2) |
yes (2,3) |
all triggers (4) |
- |
- |
DCS
ArchiveDB/OCDB |
yes! |
- |
4 |
3 |
Zero suppression |
2 Bytes/half ring |
|
20 |
0 |
< Run |
DCS or Event(2) |
yes (2,3) |
all triggers (4) |
- |
- |
DCS
ArchiveDB/OCDB |
yes! |
- |
4 |
4 |
Pedestals |
Mean&width (4+4
bytes)/strip |
|
4.10E+05 |
2.50E+08 |
2÷3 times/day |
DAQ via pedestal runs |
yes (3) |
calibration/pedestal |
1000 |
sub-event |
FEE- DAQ FES/OCDB |
yes! |
No (expected around October
2007) |
1 or 3 |
5 |
Pulser gain (1) |
4 Bytes/strip |
|
2.05E+05 |
2.00E+09 |
< Day |
DAQ via pedestal runs |
yes (3,5) |
calibration/gain scan (5) |
~1000 / strip / pulser value -> ~ 128 * 1000 * 10 = 1280000 |
sub-event/sub-run(5) |
DAQ FES/OCDB |
yes! |
No (expected around November
2006) |
1 or 3 |
6 |
Temperatures |
2 – 6 Bytes/half ring |
|
60 |
0 |
Run |
DCS |
yes (3) |
all triggers (4) |
- |
- |
DCS
ArchiveDB/OCDB |
Yes |
- |
4 |
7 |
Running conditions (6) |
4-30 Bytes/half ring |
|
300 |
0 |
Run |
DCS or Event(2) |
? |
all triggers (4) |
- |
- |
DCS
ArchiveDB/OCDB |
Yes |
- |
4 or 5 |
|
6.15E+05 |
2.25E+09 |
|
FMD Notes: |
|
1 |
Name changed to reflect actual contents |
|
Reference is the set data which are used to calculated the calibration
parameters (ex. An histogram which mean value is a calibration parameter).
These data can be optionally save in the OCDB for checks to be done offline.
These data will not be available for reconstruction. |
|
|
|
|
|
|
2 |
Running conditions like
oversampling, strips readout, zero suppression, etc. is normally set via DCS,
and the DCS logbook will contain the set-points. However, in Yves' document entitled
Calibration from the 27th of June, 2006, it is stated that for the TPC,
'Parameters of the FEE required for reconstruction, such as tail
cancellation, zero suppression, sampling frequency[,] and acquisition window
status bits, will be written by the RCU into the event trailer.' We do not currently know how to do this for
the FMD, but if it is at all possible, we'd follow that strategy as closely
as possible. Update:
I've sent a mail to Luciano, but so far I have not heard anything. |
|
Confirmed: I expect that you have talked to the system (DCS/DAQ/HLT)
experts and that they have confirmed that what you plan to do is
feasible. |
|
|
|
|
|
|
3 |
Since I'm the one that know most about the FMD FEE
these statements are not really objective :-)
I'm not really too familiar with the DCS part of the system, but we
plan to follow the TPC development closely due to similar FEE. See also note
(2) above |
|
# of required events/sample
rate': Right statistics required and/or the
sample of data in a run you plan to process to extract the calibration
parameters. |
|
|
|
|
|
|
|
4 |
This data is controlled by the
DCS, and as such does not require processing to extract. However, in certain cases, like the pulser gain calibrations, the DA
may control these without the intervention of the DCS. In that case, it's up to the DA to
propagate the information properly via FES |
|
Results:
FEE/Archive? Is that to be filled in with the
place were the intermediate results are stored? Correct, this can be either
the DCS ArchiveDB, the DAQ, DCS or HLT File Exchange server or in case you do
not need these parameters offline the FEE to which you will load the
calibration parameters through the DDL or DCS. |
|
|
|
|
|
|
5 |
Since the pulser gain calibrations require that we loop through the strips and
through pulser values, we have to have some sort of sub-run. That can be done by letting the LDC control
all aspects of the FEC. However, that
seems to imply that the detector must be software triggered. Whether software triggers are really
feasible is yet to be investigated.
Secondly, we have to test the FEC to see exactly how fast we can do
this. If we can do it fast enough,
then we can use external triggers. |
|
Accessible
b[y] offline? Is that a `yes/no' question, or is
there more? Yes or No. Yes means that
the data will be published in the Offline Calibration Data Base (OCDB). |
|
|
|
|
|
|
|
6 |
This item really covers what in the TPC case is
called 'Parameters of the FEE required for reconstruction ...' Hence, note
(2) above applies here. |
|
I
guess the column `use case #' refers to the use cases you presented some time ago, right?
Correct |
|
|
|
|
|
|
DCS
access - offline has access only to DCS archive DB, curently no access to
configuration DB |
|
|
|
|
|
|
|
|
|
DAQ
- offline has access to raw data and DAQ logbook, but no acccess to LDC or
GDC directly |
|
|
|
|
|
|
|
|
|
|
|
OCDB
- Calibration parameters are stored in the Offline Calibration DB. The data
used to calculate these parameters, the reference data, can also be
optionally archived for later access from offline. |
|
|
|
|
|
|
|
|
|
|
|
Use case 1: |
online creation in DAQ |
|
|
Calibration
parameters are computed online in the DAQ LDC/GDC/Monitoring machines from
physics or dedicated data |
|
|
Results are made
available as ROOT files in the DAQ FES |
|
|
The path of these
files together with the start and end of run timestamps is written in the DAQ
Logbook |
|
|
At the end of the run
additional processing may occur controlled by the ECS |
|
|
Upon notification by
the ECS, the SHUTTLE queries the DAQ Logbook for file name and timestamps and
fetches the appropriate parameter files |
|
|
It
stores the files into the CERN storage and adds an entry (run validity and
unique identifier of the files) into the AliEn FC |
|
|
|
|
|
|
|
|
Use case 2: |
online creation in HLT |
|
|
|
Calibration parameters are
computed online in the DAQ LDC/GDC/Monitoring machines from physics or
dedicated data |
|
|
Results are made available as ROOT files in the DAQ
FES |
|
|
The path of these files together with the start and
end of run timestamps is written in the DAQ Logbook |
|
|
At the end of the run additional processing may
occur controlled by the ECS |
|
|
Upon notification by the ECS, the SHUTTLE queries
the DAQ Logbook for file name and timestamps and fetches the appropriate
parameter files |
|
|
It stores the files into the
CERN storage and adds an entry (run validity and unique identifier of the
files) into the AliEn FC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use case 3: |
online creation in DCS |
|
|
Calibration parameters are
computed online in the DCS farm from dedicated data |
|
|
Results are made available, as ROOT files, in the
DCS FES |
|
|
The path of the produced files together with the
start and end of run timestamps is written in the DAQ Logbook or equivalent
DB |
|
|
At the end of the run additional processing may
occur controlled by the ECS |
|
|
Upon notification by the ECS, the SHUTTLE queries
the DAQ Logbook or the equivalent DB for file name and timestamps and fetches
the appropriate parameter files |
|
|
It stores the files into the
CERN storage and adds an entry (run validity and unique identifier of the
files) into the AliEn FC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use case 4: |
parameters monitored by DCS |
|
|
DCS monitored parameters are stored in the DCS
Archive DB |
|
|
At the end of the run additional processing may
occur controlled by the ECS |
|
|
Upon notification by the ECS the SHUTTLE queries
the DAQ Logbook for the start and end of run timestamps and then queries the
Archive for the relevant parameters |
|
|
The SHUTTLE pre-processors
evaluates the parameters, creating the ROOT files |
|
|
It stores the files into the
CERN storage and adds an entry (run validity and unique identifier of the
files) into the AliEn FC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use case 5: |
FEE config file |
|
|
|
The FEE parameters are fed to the electronics
either trough the DCS or through the DAQ DDL |
|
|
DCS:
files are stored in the DCS Configuration DB and on the DCS file exchange
server, the notification is done through the DCS Archive DB |
|
|
DAQ:
files are stored directly in the DAQ FES and their name registered in the
DAQ Logbook (back to Use Case 1) |
|
|
At the end of the run additional processing may
occur controlled by the ECS |
|
|
Upon notification by the ECS
the SHUTTLE queries the DCS Archive DB for timestamps and file names,
collects the data and pre-processes them (ROOTification,…) |
|
|
The SHUTTLE stores the files
into the CERN storage and adds an entry (run validity and unique identifier
of the files) into the AliEn FC |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|