1 / 30

Transverse instability observation network in LHC

Transverse instability observation network in LHC. A. Butterworth, W. Höfle , G. Kotzian , D . Val ú ch (BE/RF) T. Levens (BE/RF  BE/BI) T. Lefèvre , R. Steinhagen (BE/BI) J. Serrano, T. Włostowski (BE/CO ). Motivation.

tangia
Download Presentation

Transverse instability observation network in LHC

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. Transverse instability observation network in LHC A. Butterworth, W. Höfle, G. Kotzian, D. Valúch(BE/RF) T. Levens (BE/RF  BE/BI) T. Lefèvre, R. Steinhagen (BE/BI) J. Serrano, T. Włostowski(BE/CO) Transverse instability observation network in LHC

  2. Motivation Transverse instability observation network in LHC • Review on “Functional Requirements on LHC Transverse Instability Diagnostics after LS1” chaired by W. Höfle and R.Steinhagen, 15 March 2013 • Scope and Aims of the Review: • collect user requirements • present capabilities of existing systems and options for upgrades • ensure technology and infrastructure in place to optimally use available instruments (triggers, logging, software) • identify missing technologies and systems that need further development • prioritize requests (feasibility, resources, impact) • identify requests that cannot be fulfilled for the start-up after LS1 • recommend allocation of resources to management

  3. A. User requirements (from the Review) Transverse instability observation network in LHC • Simple information on mode (m=0 versus m≠0). Instantaneous bunch-by-bunch information can be crucial to take fast decisions for short-term ‘cures’ • ‘Light’ changes e.g. Q, Q’, octupoles, ADT gain, bunch length, filling schemes, intensity/brightness • Through the whole cycle: • Instantaneous bunch-by-bunch tunes (10-4 resolution) at an update rate of 1 Hz • Accurate knowledge of chromaticity with a precision of about 2 units at an update rate of about 0.05 Hz.

  4. A. User requirements (from the Review) Transverse instability observation network in LHC • In an interval of time of ±3 s around the moment of the instability: • Continuous “turn-by-turn” “bunch-by-bunch” positions during the instability with a resolution of a few mm • Intra-bunch time domain signal acquisition with an analogue bandwidth of about 6 GHz, 20 Gs/s sampling and transverse resolution of few mm. • Continuous bunch-by-bunch intensity at the highest rate (10 Hz) • Continuous bunch-by-bunch transverse emittance with fast scan (is a 5 Hz sequential acquisition feasible?). • Provide a snapshot of the machine when the instability occurs. This information should be stored permanently in the logging DB

  5. B. Present capabilities of existing systems and options for upgrades Transverse instability observation network in LHC • LHC transverse damper (ADT), run 1 • Two pick-ups per beam per plane at point 4 • ADT saw only symmetric oscillation patterns • Coherent oscillations are being damped • Available information - bunch position for all bunches at full 40 MHz rate, resolution ~2 mm • Available buffer length 256k bunch-turns (slow trigger, not too frequent data extraction ~1 buffer per 10 seconds) • 73 turns, all bunches • 262144 turns 1 bunch, 131072 turns 2 bunches, 65536 turns 4 bunches, 32768 turns 8 bunches • Post mortem data for the last 73 turns, beam-out trigger

  6. D. Missing technologies and systems that need further development being developed during LS1 Transverse instability observation network in LHC

  7. W. Hofle Transverse Feedback LS1 changes LMC - 5 Feb 2014 LMC - 5 Feb 2014 Reasons for change: “DSPU” • need to combine four pick-ups • Separate control for all features with high resolution calls for independent output DACs • digital links to future diagnostics HW • adequate number of spares missing needs separate discussion vision @end of Run1

  8. D. Missing technologies being developed: ADT Transverse instability observation network in LHC • Post LS1 ADT • Four pick-ups per beam, per plane, located at point 4 • Available information: bunch position for all bunches at full 40 MHz rate. Resolution (equal or better than) 2 mm • Internal buffer length increased 16x to 4M bunch-turns i.e. • 1 bunch for 4 194 304 turns • or all bunches for 1100 turns • Fast on-the-fly data analysis, can detect intra-bunch, symmetric oscillation patterns, bunch-by-bunch, within few turns and generate a trigger • Alternative data processing algorithm can also give hints on anti-symmetric oscillation patterns (see G. Kotzian et al: Sensitivity of LHC ADT to intra-bunch motion, BE-ABP-HSC meeting, 22.1. 2014) ...and generate a trigger

  9. Post LS1 ADT Longitudinal profile symmetric asymmetric Transverse oscillation pattern Normalized transverse position Movement of centre-of-charge even symmetric odd symmetric Transverse instability observation network in LHC

  10. Post LS1 ADT Normalized position as currently implemented in the BeamPosHW Movement of centre-of-charges Transverse instability observation network in LHC Damper sensitivity to symmetric intra-bunch motion is a function of the longitudinal beam spectra The current normalization scheme sees only symmetric (even) oscillation patterns (needed for closed loop feedback) For the anti-symmetric case no oscillation amplitude is detected, odd modes not visible to the damper

  11. Post LS1 ADT Alternate processing scheme to detect and indicate anti-symmetric oscillations: Transverse instability observation network in LHC This algorithm can detect odd-mode oscillations None of the algorithms can resolve the original oscillation frequency, and absolute oscillation amplitude (except m=0) But they can detect activity and distinguish between symmetric (even) and asymmetric (odd) modes of every bunch  trigger! Logging of a bunch-by-bunch snapshot for 1000 turns at the moment of trigger, with information which bunches were unstable

  12. D. Missing technologies being developed: MIM in R&D phase → possible deployment LS2 (?) Transverse instability observation network in LHC • Upgrade of the “head-tail” instrument • Classic “brute force” time-domain acquisition: next generation digitizer upgrade, 6 GHz analogue bandwidth, 20 GS/s sampling, 32 GB/channel sampling buffer (>1 s of beam data). Massive on the fly data analysis. • Multiband-Instability-Monitor (MIM), three different acquisition options: • Balanced Schottky Diode Detector. This could provide nm-level resolution and could be used as an early instability trigger, but would not allow to distinguish on which bunch the instability occurs  planned to be deployed after LS1 • Bunch-by-Bunch Balanced Schottky Diode Detector. This would provide bunch-by-bunch magnitude (no-phase information for bands > 400 MHz) data with sub-μm resolution. Needs ADC-DAQ and SW integration • Direct-Down-Conversion Receiver providing full amplitude & phase information (identical info to time-domain digitizer). Needs ADC-DAQ and SW integration

  13. Multiband Instability Monitor Transverse instability observation network in LHC MIM principle – instead of “brute force” sampling, look at discrete frequency bands (harmonics of 400MHz)

  14. Multiband Instability Monitor Instability trigger Transverse instability observation network in LHC

  15. Multiband Instability Monitor Transverse instability observation network in LHC • Minimum deliverable system (i.e. based on what has been prototyped/ demonstrated in 2012/13): • 6 analog-front-ends (ΔH, ΔV,ΣH/Vx B1/2; 16 frequency bands spread between 0.4 - 6 GHz • Will equip only 4 channels/front-end with digital-front-ends (tbc.), initially same DAB as for Diode Orbit/Beta-Beat System • Specific channels can be changed if necessary (e.g. during technical stop) • Simple triggering scheme, for details see BI Seminar 23rd Aug. 2013 & CERN-STUDENTS-Note-2013-103 • Observables • Provide an early/high-sensitivity trigger fed into the White-Rabbit Trigger Network • Distinguish whether it was rigid or intra-bunch related motion. No bunch information. • Aim at getting data logged: • continuously (e.g. eigenmode/band amplitude vs. time) • Snapshot of the raw data of all bands during the triggered instability • Help needed (OP & ABP): GUI integration, perhaps online display of amplitudes vs. time?

  16. D. Missing technologies being developed Transverse instability observation network in LHC • ADT “observation box” • Bunch-by-bunch data, with all precious beam information, are available within the ADT signal processing blocks • Difficult to extract, or store due to the very high data rates • Difficult to do sophisticated data analysis directly in the ADT FPGAs • Ambitious project proposed by the ADT team: stream the full rate data to an external computer(s): • Allows massive number crunching e.g. for tune measurement • Continuous, online analysis of the transverse (and longitudinal) motion, all kinds of fixed displays… • Storage of a full 40 MHz, bunch-by-bunch data for an entire fill for offline analysis • ……..and generate/receive a trigger

  17. ADT “observation box” ADT Beam position module Observation box receiver (PC) Bunch by bunch data read out via PCIe Processed data (e.g. tune extraction) GPU bunch #0+frev SPEC board 20ns ! Transverse instability observation network in LHC First results with data transmission and reception T. Levens Data processing by graphic chips F. Dubouchet(see. Betatron tune measurement with the LHC damper using a GPU, CERN-THESIS-2013-035) Full implementation by BE/RF/CS section

  18. C. Technology and infrastructure to optimally use available instruments (triggers, logging, software) Transverse instability observation network in LHC • Some instruments can (or will be able to) analyze the signals and generate a trigger • Most instruments in the machine have buffers with very valuable data • Very different data rates, very different record lengths • …just if we were able to freeze and use them! • We need • Fast, deterministic, configurable, machine-wide trigger distribution network (multiple inputs, multiple outputs) • To collect, store and analyze all those data.

  19. Instability trigger network functionality Transverse instability observation network in LHC A set of observation instruments can be located anywhere in the LHC or CCC

  20. Instability trigger network functionality Transverse instability observation network in LHC A set of observation instruments can be located anywhere in the LHC or CCC Many of them can generate a trigger

  21. Instability trigger network functionality Transverse instability observation network in LHC A set of observation instruments can be located anywhere in the LHC or CCC Many of them can generate a trigger Many of them can receive trigger and freeze a data buffer

  22. Instability trigger network functionality Transverse instability observation network in LHC Trigger propagation path has to be defined

  23. Instability trigger network functionality Transverse instability observation network in LHC Trigger propagation path has to be defined E.g. ADT, horizontal, B2 detected an activity

  24. Instability trigger network functionality Transverse instability observation network in LHC Trigger propagation path has to be defined E.g. ADT, horizontal, B2 detected an activity System should freeze only relevant devices

  25. Instability trigger network functionality Transverse instability observation network in LHC Sequence of triggers has to be time-stamped and each trigger originator identified Indicate to CCC that the data needs to be collected

  26. Instability trigger network functionality Transverse instability observation network in LHC Sequence of triggers has to be time-stamped and each trigger originator identified Indicate to CCC that the data needs to be collected Some instruments need the revolution frequency and beam synchronous 40 MHz signals

  27. C. Technology and infrastructure to optimally use available instruments (triggers, logging, software) • White rabbit network • Solution proposed and technology provided by the BE/CO group • During LS1 BE/RF and BE/BI invested into the White rabbit infrastructure connecting the ADT, Head Tail, future MIM, and other future instruments (e.g. diamond BLMs) • Functional specification being completed (March 2014) • Equipment installation (Summer 2014) Transverse instability observation network in LHC

  28. C. Technology and infrastructure to optimally use available instruments (triggers, logging, software) Transverse instability observation network in LHC • Software development to provide starting functionality by BE/CO critical (will be covered by T. Włostowski) • Configuration of the inputs/outputs, delays • Trigger propagation routing, re-triggering etc. • Collection of data from all instruments after a trigger (??/??) • Data storage (??/??) • measurement database, logging, special database? • CCC fixed displays (??/??) • Online/Offline data analysis (??/??)

  29. Thank you for your attention. Questions? Transverse instability observation network in LHC

More Related