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

Oversampling rate

4 Bytes/half ring

< Run

DCS or Event(2)

yes (2,3)

all triggers (4)

DCS ArchiveDB/OCDB

yes!

Strips readout

2 Bytes/half ring

< Run

DCS or Event(2)

yes (2,3)

all triggers (4)

DCS ArchiveDB/OCDB

yes!

Zero suppression

2 Bytes/half ring

< Run

DCS or Event(2)

yes (2,3)

all triggers (4)

DCS ArchiveDB/OCDB

yes!

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

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

Temperatures

2 – 6 Bytes/half ring

Run

DCS

yes (3)

all triggers (4)

DCS ArchiveDB/OCDB

Yes

Running conditions (6)

4-30 Bytes/half ring

300

Run

DCS or Event(2)

all triggers (4)

DCS ArchiveDB/OCDB

Yes

4 or 5

6.15E+05

2.25E+09

FMD Notes:

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.

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.

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.

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.

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).

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