“Technical run experience ”

Post on 14-Jan-2016

28 views 0 download

Tags:

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 Presentation

transcript

“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?)