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
Peter Chochula, January 31, 2006
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
Peter Chochula, January 31, 2006
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.
Peter Chochula, January 31, 2006
the data flow for different running modes
Peter Chochula, January 31, 2006
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?
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)
Peter Chochula, January 31, 2006
Calibration procedures for TPC (2)
Calibration Pulser1. Once (or more per run) 2. No Gating pulser 3. Trigger: Pulser 4. Take data for offline analysis
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
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
Peter Chochula, January 31, 2006
organization of configuration records
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)?
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?
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?)
Peter Chochula, January 31, 2006
dependencies on external data sources ( e.g. database of positions ofsuper modules)
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)?
Peter Chochula, January 31, 2006
Monitored data and data to be sent to offline
Peter Chochula, January 31, 2006
Monitored TPC FERO Parameters
4500*5 parameters 4500 statuses
Peter Chochula, January 31, 2006
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
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)
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?
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
Top Related