“technical run experience ”
DESCRIPTION
“Technical run experience ”. Gianluca Lamanna (CERN) TDAQ meeting 11.12.2012. Summary (1). The technical run started in October 29 Excellent participation from all the collaboration Good support from (almost) all the sub-detectors and sub-systems experts - PowerPoint PPT PresentationTRANSCRIPT
“Technical run experience”
Gianluca Lamanna (CERN)
TDAQ meeting 11.12.2012
Summary (1)
The technical run started in October 29Excellent participation from all the collaborationGood support from (almost) all the sub-detectors and sub-systems expertsSeveral stops and delays due to “external” problems: magnets, main PS power supply, doors and ….water
ECN3
Summary (2)
Two parts:Test beamTechnical run
Test beam: data collected in “standalone”Several software used (Karim’s, Lav’s, Chanti’s): reading of the input buffers (the first 2000 words)Mainly muon runs
Technical run: data collected with the full system. Several runs collected with different:
Beam conditions (pencil, “real” (low and high intensity, muons)Triggers (Q1*MUV3, Q1*NHOD, Q1*MUV2, Q1, Q1*MUV2*!NHOD)Detectors included (CHANTI yes/no, detectors excluded for temporary failure,…)Random triggers (with and without beam)
Summary (3)
https://twiki.cern.ch/twiki/bin/viewauth/NA62/RunBookThe runbook information will be completed with the information from the run control Partial list of runs (with stable conditions) compiled by Giuseppe
Success or failure?
Installation of a complex systemReadout boardsTrigger distributionNetworkPCFARM, Run Control, CDRDetectors, HV, DCS,…
Commissioning building of several pieces
Beam commissioningControl room ancillary systems
Collected more than 150 GB of dataReinforcement of the collaborationBut the main success is in …
Success or failure?
…all the mistakes we have made!
Each bugs, malfunction, instability, crazy behavior, etc. we observed, will help to build a “perfect” system more than the data collected!
Keywords
TALK TEL62
DIM
NETWORK
RunControl
OnlineMonitor
CLOCK
PCFARMELOG
CDR
TRIGGER
DCS
TALK (a.k.a. L0TP)
No major issue Well known limitations
maximum number of NIM trigger sources (4) maximum latency, …
Limitations due to the firmware: limited (and hard coded) number of trigger configurations impossibility to downscaling single triggers mixture of trigger possible but not tested missed automatic logging of L0TP configuration
Main problem: apparently the trigger offset depends on the firmwareLab investigation (not so easy)
Clock & Alignment
Issue with the phase of the SOB to the LKrTrigger offset alignment in two steps:
Coarse: looking directly the data in the output buffersFine: automatic scan
Trigger scan repeated before any trigger change
chod
lav3
cedar
Clock & Alignment
Very important: Is it the SOB jitter low “enough”? (Vlado’s question)
Try to look in to the data: accuracy limited by the detector time resolutionDesign a way to test the electronics in a controlled situation (in the lab and in the cavern)
Choke&Error test not completed
clockTALK
TALKSOB
LTU/TTCex
LTU/TTCex
TEL62
TEL62
TEL62
Theoretical limitation to 200 kHz (in the present design) never reached due to firmware bugs
The most tricky (in the DDR part) was very difficult to be discovered in lab testOther bugs in the SL fixed but not tested
No evidence of hardware design problems (within the tests done)Strategy to allow extensive tests in the lab (in TR like conditions)
Marco’s talk
DIM
Several problems due to DIM stabilityLoss of connection with CCPCRare loss of connection with L0TPSomething to investigate in the PCFARM
Some problem due to the network infrastructureFix or change the systemExtensive tests needed, redesign of the DIM service
DNS(lkrpn2)
PCFARM
MERGER
RunControl
TEL62
SLM
L0TP
Network
Prompt help from the IT division main structure, multicast, …
Still not everything perfect adding a new boards require some job
The network bandwidth has not been testedThe network structure for the trigger primitives transmission has not been tested
Run Control
Big improvements during the runSeveral problems pointed out during the data taking has been fixed in the last version (not tested)Most of the problems during the runs (stops, errors, black magic with the farm…) are related to DIM
Nicolas’ talk
PCFARM & CDR
The PCFARM worked well during the run:
Only one PC testedNot rate test performedStill missing L1&L2
Problems with DIM interface (to be fixed)Still licenses missed (we have only two)The CDR worked well
GPN data transfer10 Gb fibers installation to be completed and tested
Online monitor
The technical run gives a big boost to the reconstruction software and the online monitor
Still some detector needs improvementSeveral “temporary”, ”last minute”, ”incompleted” solutions to be reviseted
The general structure is working:
first step for the event display
DCS
A lot of job to improve the reliability of the DCS during the whole TR
Several problems remain on the stability of the OPC serverStill problems of reliability
DCS for LAVFEE was not working until the second half of the TR
Still the MUV2 control isn’t ready
Elog & Twiki
Two power full tools not completelly exploited:
Experience to improve the elog interface (additional categories, electronics shift list, …)Not all the information has been placed on Twiki
Trigger primitives
A preliminary trigger primitives test has been done (Dec. 1)A bug in some configuration scripts prevents to completed the test
The most critical parts has been tested (primitives generation and primitives transmission)
The network for the primitives transmission hasn’t been tested
Next steps
Design the strategies to test the system without beam (electronics pulsers, leds, etc.)Build the hardware neededComplete the remaining firmwareBuild the missed hardware (Straw tel62 interface, final L0TP, …)New Dry Run(s) ! (one long or two short? next summer?)