1 / 24

DT & Ali Readiness

DT & Ali Readiness. Update of the discussions at the Muon Barrel Workshop on Oct 5-7 http://indico.cern.ch/conferenceDisplay.py?confId=69142. 2009 Nov 3 Detector, infrastructure, HV,LV,DCS,DSS (Alberto Benvenuti) Electronics (minicrates,Tower) and spares (Cristina Fernandez Bedoya)

yitta
Download Presentation

DT & Ali Readiness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DT & Ali Readiness Update of the discussions at the Muon Barrel Workshop on Oct 5-7 http://indico.cern.ch/conferenceDisplay.py?confId=69142 2009 Nov 3 Detector, infrastructure, HV,LV,DCS,DSS (Alberto Benvenuti) Electronics (minicrates,Tower) and spares (Cristina Fernandez Bedoya) Data Acquisition, monitoring, run strategies (Roberto Carlin) Synchronisation (coarse, fine) (Luigi Guiducci) DQM, Calibration, prompt-offline (Mary-Cruz Fouz) Alignment (Gervasio Gomez) Shift coverage, tasks coverage (MDV)

  2. HV Problems ( 0.1%) • these can be reduced to 10 after intervention next time CMS opens

  3. Safety: Central Shifter GUI • DT passed the Action Matrix Review (three times) From stand-by to on: currently it is responsibility of the DT shifter. Automatic when central signals available. Sets DT in “safe mode” HV at 2000V/1800V/-1200V for LHC Operation

  4. Incidents • The DT system survived a significant water leak in YE+1 that generated HV trips in 18 chambers: 8 in YB+2, 8 in YB+1 and 2 in YB-2 • All chambers recovered (No additional HV Problems) • ALL MiniCrates are working (But long term damage might appear) • A LV connector was damaged by over heating caused by a combination of a bad crimp, a weak connector and high current. • 7 cables that showed anomalous voltage drops have been re-crimped • We are investigating methods to make the connection more robust • A campaign of refurbishing the LV connections will be done in January • Monitoring of the power supplies has been strengthened • At present all cables have normal voltage drops • There are no safety issues for the detector

  5. DT electronics failures Since closing 2008 ~ 1,2 % detector lost -- all fixed Since closing 2009 ~ 0,5 % lost (1 SL, 1 ROB, 3 TRB, 1 CCBlink1º) Summary of MiniCrate problems in terms of component: * Weak parts identified (ROBUS connector, BTI modules, CCBlink), number of failures small and low impact * Failure rates are decreasing Tower electronics and USC: 1 TIM board replaced YB+1 top in June 2009 1 TIM + 3 Optorx (TSC) replaced after LHC clock tests

  6. DT electronics spares * Spares number is adequate * Most of spares at P5. At present, effort is being done in organizing spares storage.

  7. DAQ and monitoring software • Many improvements in the last months • Extensive use of the database • All configurations for HW, for the DAQ and for the trigger; thresholds for monitor and alarms; masks for bad channels and known errors • Everything is traceable • web-based interfaces make the remote monitoring efficient • Example: summary dashboard (next slide) • Recently lot of development on the trigger supervisor • deployed and reliable • contains tools for coarse and fine synch

  8. DT dashboard: one page summary of everything

  9. Firmware • Last large functional firmware upgrade in spring 2009 • ROS, DDU, Mini-crates, trigger • mostly to improve error handling and monitoring • with the exception of some trigger LUT bug fixes in summer • stable, thoroughly tested in CRAFT • Recently only small patches • to improve some monitoring features • change in mini-crates power-on sequence useful in maintenance periods • partitioned power-up to avoid thermal stresses when some device is not needed) • Ready to run

  10. Recent problems with clock OptoRX modules ( 60, one per sector)) connect DT with DTTF Some modules, that “lock” OK at stable frequencies ( injection, flat-top), fail during clock sweeps (proton ramp after injection) • this generates high trigger rate • Will be replaced not totally certain that the trigger spikes can be totally eliminated during the ramps

  11. DT states Basic state: HV in stand-by, LV on, MC configured, DAQ ready • Ready to start a run as soon as the LHC clock is declared stable (LHC ready to inject) • HV will go to nominal only after ramp so no DT trigger expected during injection and ramp • IF abnormal trigger rate during clock sweep, it is proposed to prescale DT triggers and recover operation with a pause-resynch-resume transition • It should not happen after OptoRX fix, but…. • Most of calibration data is collected during abort gaps • no need of regular calibration runs in the fill gaps (HV will be in stand-by anyway) • We would like to participate in inter-fill runs anyway to keep the system warm and spot quickly possible problems

  12. DT Local Trigger synchronization workflow • offline/online workflow for tuning the DT Trigger synchronization parameters (delays) is ~ready • analysis based on comparison of track arrival time (pp) to trigger efficiency reference curve (cosmics, per-chamber) • all delays use DBs (both online and offline) • onlinesoftware (trigger supervisor) can adapt the trigger chain synchronization to new delays automatically using fast test which generates new DB keys (few minutes) • after initial synchronization, tools can be used to monitor synchronization stability 1/efficiency reference curve (cosmics) ns (*) track arrival time ns

  13. Synchronization vs LHC startup (statistics) • Startup synchronization and calibration based on TOF from simulation • ensure BX level synchronization • Beam-splash events • Nothing we can really do. Muons // to phi wires (no BXID) + wrong TOF • 900 GeV (2 TeV) commissioning • Assume ~ 1nb-1 collected • Should mean ~10k mu (PT > 4 GeV/c), ~1k mu (PT > 7 GeV/c, ~reach MB4s) • Validate coarse (BX level) Barrel Synchronization • Validate synchronization with the rest of L1 • Not enough stats for fine synch • 7 TeV collisions in 2010 • Phase called “Pilot physics combined with commissioning” • Max 43 bunches, L=9x1029, stated about ~200 nb-1 • Thats’ already several hundred thousand muons PT >7 GeV/c • We need - say - 300 mu/sector; ~ 20k muons; ~ 10 nb-1 !!! • First day above 1029 is enough for fine synchro workflow

  14. DT Performance Monitoring DQM (Online, Offline) & Prompt Offline The DQM and Prompt Offline provide fast feedback on the readout, chamber and trigger status by monitoring: Readout status Occupancies Noise Timeboxes Chamber & Trigger efficiencies Segment & Trigger qualities ………….. Summary histograms allow to have a clear (and fast) general overview of the system and spot problems. The large quantity of detailed histograms help on the understanding of eventual problems and are very useful for experts

  15. Calibration Track position=Time x Driftvelocity tprop= Propagation time along wire Time= TDCTime – t0(wire) - tTrig (SL) - tprop Noise Will be monitored and DB updated when needed Drift velocity A DB for the start up (precision depends on the tTrig precision), will be monitored and DB updated if needed. T0 calibration: DB available, the values should be stable  We need monitoring via the Test Pulse runs tTrig CRAFT tTrig calibration Values calculated for the start up are different from cosmic runs. We can compute the values for start up correcting the values from cosmics  A new DB will be available very soon @ CRAFT: Different values top-bottom due to TOF @ LHC: uniform distribution vs Sector number

  16. Calibration workflow • The minimal number to have a reasonable calibration (tTrig, Vdrift) • ~2500 muons/sector Technically the calibration workflow takes less than a day. However, at the beginning we expect ~0.01Hz/Chamber It will take some time (~1 week?) to have enough statistics for improving the calibration of each single chamber BUT  Global changes (BX Level) in the trigger latencies can be adjusted easily “by hand” from the first day Calibration @ CRAFT:1 Shifter per day + 1 Expert The shifters were people with knowledge on the procedures Calibration during pp running - After the first period of data taken we will merge the calibration shifter with the prompt offline shifter. - The calibration expert (mainly on-call) will be maintained The shifter will run the programs and the expert should - Certify the goodness of the computed values. - Evaluate the need of uploading or not new constants and do it.

  17. Prompt Offline & Performance studies 2 Shifts/day(no night shifts) (Till now most of them from remote) 1 expert(9:00 – 21:00) - Provides help to shifters in case of problems - Supervise the work reviewing also some of the runs to spot “less evident” problems. - Make specific analysis when needed. Till now only 3 persons available for expert (weekly) shifts. To cover the ~1 year pp running we need 10 people. On top of the prompt offline analysis more detailed analyses are needed to investigate specific problems in the performance of our system (chambers & trigger). It is important to have a group of people that: - Perform systematic studies on the data - Work on any problems that can appear during data taken. The Prompt Offline experts should deal with the problems, sometimes he/she can solve/understand them fast but for others he can need to trigger some more work by the proper experts

  18. Shifts and tasks coverage: CERN resident team • Efficient run implies a good team of on-call experts to back up shifters • The DT-Ali collaboration will support 1 expert resident at CERN and available on-call 24/7 for each of the following tasks:

  19. Shifts and tasks coverage: remote assistance • DT-Ali institutes have also taken commitment on on-call 24/7 assistance by the designers/developers and institute experts in case of problems that cannot be solved by the CERN resident team and/or fast analysis feeback

  20. Alignment Readiness • DCS Integration • Alignment Manual ready: Link+Barrel+Endcap+LV • Final DCS integration waiting for common PVSS node • Not yet gone through formal procedure for integration • Working on action matrix • Alignment shifts • Until DCS integration, done by each alignment subgroup • pass to global DCS shifter after integration • Usually one alignment run per subsystem per day • relatively light since not 24/7 • Hardware issues • NO problems detected as a consequence of leak incidents • Few hardware failures • None are serious: alignment not compromised due to these • Online programs and monitoring • No online DQM for alignment (at least not yet) • Online scripts do exist that provide live z-bar information • should be extended to other analog and optical sensors • Track-based alignment ready • algorithms developed and waiting for pp tracks

  21. Alignment constants workflow • Detailed status of optical alignment reconstruction status: • Currently, hardware constants have been calculated for the whole muon spectrometer • DTs • Ready at the 90%. Still missing closure of the barrel volume in order to provide a complete stand-alone geometry • Link sectors to global CMS coordinates independently • constants are being validated. In progress now with CRAFT09 constants • CSCs • Reconstruction completed adding all d.o.f. measured by the system. • Validation with tracks more difficult (not complete analysis with cosmics). Use halo and collision tracks • CSC linking to tracker already cross-checked (technically ok) • Link wrt Tracker: • Reconstruction completed. • Relation with tracker is weak: AR relation with central-barrel tracker done with tracks.

  22. Additional info

  23. 4 4 4 4 4 3 3 3 3 3 5 5 5 5 5 2 2 2 2 2 6 6 6 6 6 1 1 1 1 1 7 7 7 7 7 12 12 12 12 12 8 8 8 8 8 11 11 11 11 11 9 9 9 9 9 10 10 10 10 10 Problems appeared after 2009 detector closing – October 2009 Status 2 FrontEnd 3 ROB 5 TRIGGER 3 MC generic 1 Primary link -1 2 -2 1 0 Does not mean components, but places where a problem has been found

  24. MB1 MB2 MB3 MB4 Bad synchronization DT Monitoring Some examples Bad tTrig

More Related