Peter Chochula, January 31, 2006 Motivation for this meeting: Get together experts from different...

Peter Chochula, January 31, 2006

Motivation for this meeting: Get together experts from different fields See what do we know See what is missing See what is needed and when Who is doing what

In particular we will focus on FERO configuration and data flow

Some questions will be raised in this introduction, we will come back to them during this meeting If we are not able to answer them, we must

define who will answer and when


References: 11th, 12th and 13th DCS Workshops ALICE offline calibration workshops FED API 2.0 TPC/TRD meeting during ALICE week in

October 2005

Documents and transparencies are available on the DCS web


Topics to be adressed during this meeting

the data flow for different running modes: the calibration, pedestaltaking etc. and requirements towards the DCS- synchronization of DCS, TRG and DAQ via ECS during the special(calibration) runs- the full chain from raw data to configuration records in the database

organization of configuration records, structure and size of database tables, access patterns, sharing of data between the DCS and DAQ data caching by FED servers ?

dependencies on external data ( e.g. database of positions ofsuper modules)

Monitored data and data to be sent to offline: what should be sent to conditionsdatabase, how should be the configuration records made available for offline etc.


the data flow for different running modes


Basic dataflow during the calibration

FERO Configuration Database

Calibration Procedure

(online systems)

Analysis Procedure

DCS ArchiveDAQ Data

How is the FERO loaded ?By whom?What version?

What are the calibration steps?What data is acquired ?

By whom?Where is it stored?

How is the analysis performed?

what data is needed and where, how is it transferred?How is the data inserted back to the configuration database?


Pedestal taking 1. Once (or more per run) 2. HV: on or off (on only without

beam) 3. FERO: Taking raw data without zero

suppression 4. Trigger: random trigger 5. Gating pulser on 6. Calculation of averages 7. Generating of Altro code -> write

into database 8. Push from Database to Fero (via

DCS or DDL)

Calibration procedures for TPC (1)



Calibration Pulser1. Once (or more per run) 2. No Gating pulser 3. Trigger: Pulser 4. Take data for offline analysis



Laser Calibration 1. Normal operation mode 2. Trigger: laser or 3. Laser triggered external?4. Two modes wanted:

• Exclusive laser run • Once (or more per run)

• Laser embedded in normal run • Continues

5. Take data for offline Analysis



Krypton calibration run 1. Before and after beam times (shutdown phases) 2. Special gas system operation (manual) 3. Random trigger 4. Gating triggered (closed ?) 5. HV reduced voltage settings


organization of configuration records


The agreed strategy is: All FERO data is stored in the configuration database

(ORACLE) DAQ needs the data in files

These files are retrieved from the database and stored in DAQ computers The files are not recreated dynamically (eg. on each

configuration request) FED accesses the configuration database directly

Q: Could the FED maintain a local cache of this data?Q: Should all data go to the DB (eg. TPC pedestals)Q: What data and in what format is needed for offline

(can we re-use the DAQ configuration files)?


Present strategy is to store the configuration data in form of BLOBs Conversion to DAQ configuration files and/or

local FED cache should be straightforward Data size (assuming 200kB/RCU):

~43 MB for TPC ~108 MB for TRD

TPC pedestals are not taken into account here!Q: Should these pedestals really reside in the

database?


TPC and TRD can perform FERO reconfiguration during the run if needed.

It is not necessary to stop the run, because the data is loaded using the DCS board

Q: is this safe?Q: who should be informed? (e.g. offline

might want to know that the physics data was possibly biased by wrong FERO settings for a period of time – do we know for how long?)


dependencies on external data sources ( e.g. database of positions ofsuper modules)


TRD requests a ling to an external database of super module positions

(My) Remark: This request should be carefully studied, the DCS should not depend on external sources and must operate also when the DCS network is disconnected from outside world

Q: What else do we need to take into account (e.g. any dependencies on the DCDB – static configuration)?


Monitored data and data to be sent to offline


Monitored TPC FERO Parameters

4500*5 parameters 4500 statuses


Monitored TRD FERO Parameters/ Offline Conddb

Source: TRD URD

1. MCM temperature2. user ADC3. pulsing pattern4. pedestals5. zero suppression

thresholds6. memory7. user I/O8. MCM status9. exceptions

Source: Offline (Dariusz Miskowiec)*

1. clock frequency 2. number of time bins3. list of masked channels

4. list of active chambers 5. ADC thresholds6. temperature

* These parameters should be collected for each run and sent to offline

Source: 11th DCS Workshop (Q&A)

1. 18*6*4 Voltages2. Some temperatures

(DCS board)3. Eventually 65000

temperatures from MCM


Q: How can we assure that online and offline is talking about the same parameters? (information flow between different groups)

Q: What is the final list of monitored parameters?

Q: What are the corresponding DIM services?Q: What are the monitoring limits, alarm

limits, emergency actions?Q: Who is responsible for defining the PVSS

part within the detector groups ?(the FED should be described as a FW device with its settings stored in the configuration database)


Q: What services on DCS side are needed and when?

Q: How are we going to test the full chain and when?

Q: What else we forgot to mention?


Agenda for this meeting

Introduction (P.Ch.) – DONE! TRD overview (Kai) TPC overview (Uli) DB tests (Sve) TPC and TRD configuration records

(Roland) FED status (Benjamin)

Discussion – all

Peter Chochula, January 31, 2006 Motivation for this meeting: Get together experts from different...

Documents

Transcript of Peter Chochula, January 31, 2006 Motivation for this meeting: Get together experts from different...