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

2. Peter Chochula, January 31, 2006  References: 11 th, 12 th and 13 th 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

3. Peter Chochula, January 31, 2006 Topics to be adressed during this meeting  the data flow for different running modes: the calibration, pedestal taking 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 of super modules)  Monitored data and data to be sent to offline: what should be sent to conditions database, how should be the configuration records made available for offline etc.

4. Peter Chochula, January 31, 2006  the data flow for different running modes

5. Peter Chochula, January 31, 2006 Basic dataflow during the calibration FERO Configuration Database Calibration Procedure (online systems) Analysis Procedure DCS Archive DAQ 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?

6. Peter Chochula, January 31, 2006 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)

7. Peter Chochula, January 31, 2006 Calibration procedures for TPC (2) Calibration Pulser 1.Once (or more per run) 2.No Gating pulser 3.Trigger: Pulser 4.Take data for offline analysis

8. Peter Chochula, January 31, 2006 Calibration procedures for TPC (3) 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

9. Peter Chochula, January 31, 2006 Calibration procedures for TPC (4) 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

10. Peter Chochula, January 31, 2006  organization of configuration records

11. Peter Chochula, January 31, 2006  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)?

12. Peter Chochula, January 31, 2006  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?

13. Peter Chochula, January 31, 2006 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?)

14. Peter Chochula, January 31, 2006  dependencies on external data sources ( e.g. database of positions of super modules)

15. Peter Chochula, January 31, 2006  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)?

16. Peter Chochula, January 31, 2006  Monitored data and data to be sent to offline

17. Peter Chochula, January 31, 2006 Monitored TPC FERO Parameters  4500*5 parameters  4500 statuses

18. Peter Chochula, January 31, 2006 Monitored TRD FERO Parameters/ Offline Conddb Source: TRD URD 1.MCM temperature 2.user ADC 3.pulsing pattern 4.pedestals 5.zero suppression thresholds 6.memory 7.user I/O 8.MCM status 9.exceptions Source: Offline (Dariusz Miskowiec)* 1.clock frequency 2.number of time bins 3.list of masked channels 4.list of active chambers 5.ADC thresholds 6.temperature * These parameters should be collected for each run and sent to offline Source: 11 th DCS Workshop (Q&A) 1.18*6*4 Voltages 2.Some temperatures (DCS board) 3.Eventually 65000 temperatures from MCM

19. Peter Chochula, January 31, 2006 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)

20. Peter Chochula, January 31, 2006 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?

21. Peter Chochula, January 31, 2006 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