Programmed dumps (incl. inject & dump)

Programmed dumps (incl. inject & dump) • LBDS functional architecture • Use-case overviews • Inject and dump between 0 – 1000 turns • Inject and dump between 0.1 and 1000 seconds • Programmed dumps during injection process • Programmed dump at end-of-fill • Programmed dump of one beam • Requirements on other systems • Implementation • Annex (use-case details)

LBDs functional architecture • LBDS interfaces for arming, triggering and energy tracking: • DCCTs in 4 of the LHC arcs, and in IR6, for the BETS; • RF system, for the abort gap fast timing; • injection interlock system, to allow the dump to be armed; • BIS beam interlock system via the local BIC client interface; • redundant IR6 beam loss system, to trigger LBDS independently of BIS; • access system, to dump beam without passing through BIS;

Inject and dump I: 0 – 1000 turns • For injection setting-up with screens, and studies requiring less than 100 ms of circulating beam, e.g. aperture measurements in injection/extraction channel. • Will use a dedicated hardware system to trigger the beam dump via the BIS • Necessary to dump after less than one full turn, to ensure that injection setting up with screens can be performed with a single beam impact. • To protect the screens, maximum number of turns has to be limited. • Preferable that this mode limited to Safe Beam from SPS – if not, then procedure is more complicated, requiring pilot injection prior to high-intensity injection, to ensure circulating beam condition is met. • The other entry conditions are that the LHC machine is at injection energy, that the beam permit for the selected ring is TRUE. • Use a timing event at 100 ms (or even few ms after the requested number of turns) to provide redundancy for increased screen protection

Inject and dump II: 0.1 – 1000 seconds • This mode is required for longer delays between injecting and dumping • Will use the timing system to trigger the beam dump via the BIS. • Screens are NOT allowed to be in the beam • Again, for simplicity, it would be preferred that this mode can only be used with the Safe Beam from the SPS, but this is less important since interlocking should anyway ensure that the screens cannot be used

Dump of intermediate beam during injection • A programmed dump during the nominal injection sequence is required to dispose of the intermediate beam injected after the pilot bunch (cannot be dumped ‘parasitically’ onto the TDI injection collimator). • Will use the timing system to trigger the beam dump via the BIS. • Variations on the theme will be needed, according to whether both rings are filled alternately or sequentially, and on the details of the adjustment and filling phases. • The question of whether the BIS/LBDS should enforce a dump of both rings in the event of a beam permit FALSE for one ring still needs to be decided – it would increase the operational flexibility, but reduce the safety, since some interlock channels with separate signals for beam 1 and beam 2 may be cross-connected. Work in progress with interlock team e.g. on making this conditional on machine mode.

Dump of both beams at end-of-fill • A programmed dump at the end-of-fill will be required, for example when the specific luminosity is low enough that the machine requires refilling. • Will use the timing system to trigger the beam dump via the BIS. • The dump request will be managed by the sequencer, which must make sure that the entry conditions are satisfied, and that any preparatory steps concerning e.g. the experiments, the movable devices etc. are first executed

Dump of one beam • A programmed dump of one beam is a possible requirement, for example for machine studies at the end of a fill. • Will use the timing system to trigger the beam dump via the BIS. • The dump request will be managed by the sequencer, which must make sure that the entry conditions are satisfied, and that any preparatory steps concerning e.g. the experiments, the movable devices etc. are first executed. • Condition under which this is possible need definition

Protection of BTV screens at injection • “Inject and Dump I” mode needed to ensure protection of screens – only used when LHC is in this mode AND turns requested less than safe limit (depends on screen type (Al2O3 or Ti) and intensity) • Assuming only safe beam can be used • Al2O3 screens withstand 1013 p+/mm2, and Ti screens 1014 p+/mm2. For nominal optics, p+ density at screen for injected nominal batch of 3.31013 p+ is ≤1.11013 P+/mm2. • Assuming that the safe beam limit is 1012 p+ at 450 GeV, safe number of turns for Ti screens is ~ 300, and for Al2O3 screens ~30. • Taking 3 margin, max. turns with safe beam should be 100 for Ti and 10 for Al2O3 screens. • To be implemented in SW interlock which uses number of turns requested and screen position to allow or inhibit injection. • HW interlock from screens to inhibit user permit for unsafe beam, if screen in beam. • Assuming any beam can be used • Product of [turns  intensity] must not exceed 1013 for Al2O3, and 1014 for Ti screen (i.e. 3 turns with full intensity, or 2104 turns with pilot bunch). • To be implemented in SW interlock which uses measured beam intensity (in SPS), number of turns requested and screen position to allow or inhibit injection. • Additional protection measures • Limit the maximum number of turns to 1000 in Inject & Dump I HW • In this mode always include a timing event at 100 ms (or more closely linked to turns requested). • As a real HW interlock with no software dependence, use BLMs at each screen, with interlock threshold at an appropriate integration time, to dump beam if losses detected exceed dangerous level.

Interlock and dump systems • BIS used to trigger beam dump for all programmed dumps. BIS must therefore provide a reliable and deterministic response to interrupt in IR6 coming from Inject and Dump I system, such that beam can reliably be dumped after programmed number of turns. • BIS must also provide an automatic reset for certain machine modes, in order that repeated injection or injection sequence can continue. (Alternatively such functionality could be provided by sequencer which works in a quasi real-time loop?) • The following functionalities are required: • Triggering via timing system (delay can be of the order of a few turns) • Automatic reset conditional on machine mode (from SMP) • SW input channel for XPOC inhibit • LBDS must be re-armed after every action, which is foreseen to be requested by the sequencer. • LBDS IPOC and XPOC results must be positive and beam permit loop is then forced close during a short period, while LBDS inhibits injection and forces its own user permit true.

Timing, RF and SMP systems • The timing system will be used for the Inject and Dump II mode and for the other programmed dump events. The following timing system functionalities are required: • Distributing “Programmed dump” • Distributing “XPOC request” events (tbc) • Distributing “PM request” events conditional on machine mode and dump type • The following RF system functionalities are required: • Injection prepulse to IR6 (RA63/67) – assume 10 s before injection (tbc). Needs new fibres. • Revolution frequency to IR6 (RA63/67) – already exists to LBDS TSU • For the Safe Machine Parameters the LHC mode must be distributed to the BIS, for conditioning the automatic reset (alternatively mode must be available to the sequencer which will manage reset). • The mode is also needed for the screens, to prevent any movement while beam can be injected or present.

Beam screens and SW interlocks • The beam screens must be protected against damage, and this requires interlocking on their position, conditional on the machine mode and intensity. • The following functionalities are required: • HW interlock if moving • HW interlock if unsafe beam (tbc depending if Inject & Dump I limited to safe beam) • Read of screen position and type (for SW interlock) • Dedicated interlock BLMs with thresholds adapted to protect the screens • Movement inhibited in any machine mode where beam can be present • The following SW interlocks are required: • Inhibit injection if screens moving • Inhibit injection if screens in beam and unsafe beam (tbc) • Inhibit injection if screens in beam and machine mode <> Inject and Dump I • Inhibit injection if screens in beam and I&D I system turns >100 • Inhibit injection if screens in beam and [turns  intensity] > 1013 (Al2O3) or 1014 (Ti)

Sequencer and XPOC • The sequencer must provide the high-level management of the inject and dump machine modes and of the other programmed dumps. The following functionalities are required: • managing machine mode changes • configuring all the systems to meet the entry conditions • checking that the entry conditions are met • generating the timing events with the correct delays • setting the turn counter value • requesting checks before injection is enabled • requesting the correct beam from the SPS • reading the XPOC result • arming and re-arming the LBDS • re-arming the BIS (tbc) • The XPOC needs to acquire and check data associated with beam dump action. The process must inhibit beam permit via a software channel while busy. The XPOC needs to return an answer within about 10 s, in order to allow for repeated injections in Inject and Dump mode.

Implementation • BT (i.e. Etienne) will build the new HW • Schematic architecture of LBDS with new inject and dump crate shown below

New Inject & Dump HW • Assumed HW located in a rack or racks in point 6 underground, in RA63/67, to minimise the reaction times with the beam permit loop. • Present prepulse envisaged 10 s prior to injection, to minimise ‘dead time’ of MKI when injection kick can no longer be stopped. • Detailed analysis of response times and signal delays to be made, to determine whether this is adequate for deterministic dumping on turn 0, or whether another separate prepulse needs to be generated with a longer delay to trigger this system. • The following functionalities are required: • Triggering by RF prepulse • Turn counting via RF frequency • Interrupt of beam permit loop • Adjustable delay in order to trim the system synchronisation during setting up • “Set” requested turns via LSA (MCS?) • “Read” of requested turns via LSA (for SW interlocks)

Issues • Need a better name than “Inject and Dump I system”…. • Limit inject and dump I mode (with 0 – 1000 turns) to safe beam intensity? • Easier to implement & safer for screens • Operational constraints? • Are the limits 0 – 1000 turns and 0.1 – 1000 seconds reasonable? • Is 10 ms injection prepulse delay enough for 0 turns? • Delay accounting and tests to be made • Otherwise need separate pre-pulse with few 100 ms? • Is the proposed protection for the screens adequate? • Not clear that local private turn counters safer: BLMs to be defined and feasibility checked • To be discussed in upcoming MPWG… • Conditions to dump one beam? Arm & inject with other beam permit false? • Automatic reset of BIS: are we sure that this does not impact the reliability? • Sequencer: work still to be done to define detailed requirements • Can this be used to reset the BIS? • XPOC and PM triggering, data acquisition and pathways: work still needed • LHC machine mode details • Can “Inject and dump I” and “Inject and dump II” be combined? Interlocking implications? • Present definitions require extension – links to sequencing and interlocking

Use-case details

Inject and dump I: 0 – 1000 turns i. Machine mode is changed to “Inject and Dump I” by the LHC sequencer ii. Number of turns selected between 0 and 1000 and loaded into Inject and Dump hardware by sequencer iii. “Request dump” Timing event delay set at 100 ms or corresponding value iv. Checks made of screen positions and requested turns resident in the Inject and Dump hardware by the LHC sequencer - injection is inhibited if: a. screens are MOVING; b. OR the screens are IN and the mode is not “Inject and Dump I”; c. OR the number of turns requested exceeds the safe limit. v. Safe beam is requested from the SPS by the LHC sequencer vi. Beam is injected and the turn-counter triggered in the Inject and Dump hardware; vii. After the programmed number of turns, the Inject and Dump Hardware triggers beam dump via BIS; viii. The timing system generates a “request XPOC” timing event, after receiving a dump request associated with a “request dump” timing event while in “Inject and Dump I” mode – OR – specific shot-by-shot transient data logging data is acquired, associated with the injection and with the beam dump. No “request PM” event is issued; ix. The XPOC process inhibits the injection by the SW user permit channel of the BIS x. The data required for the XPOC is transferred to the servers and analysed by the XPOC process; xi. If the dump action was correctly executed the XPOC process gives the user permit; xii. The BIS makes an automatic reset, possible for “Inject and Dump I” Machine Mode; xiii. The sequencer launches the “arm LBDS” sub-sequence

Inject and dump II: 0.1 – 1000 seconds i. Machine mode is changed to “Inject and Dump II” by the LHC sequencer ii. Delay time selected between 0.1 and 1000 seconds and loaded into the timing system by the LHC sequencer iii. Checks are made of injection screen positions and screen types by the LHC sequencer - injection is inhibited if any screens are IN or MOVING iv. Safe beam is requested from the SPS by the LHC sequencer v. Beam is injected; vi. After the appropriate delay, the timing system issues an event which is received by the BIS and triggers the beam dump by opening the beam permit loop; • No “request PM” event is issued. The timing system generates a “request XPOC” timing event, after receiving a dump request associated with a “request dump” timing event while in “Inject and Dump II” mode – OR – specific shot-by-shot transient data logging data is acquired, associated with the injection and with the beam dump. • The XPOC process inhibits the injection by the SW user permit channel of the BIS ix. The data required for the XPOC is transferred to the servers and analysed by the XPOC process; x. If the dump action was correctly executed the XPOC process gives the user permit; xi. The BIS makes an automatic reset, possible for “Inject and Dump II” Machine Mode; xii. The sequencer launches the “arm LBDS” sub-sequence;

Inject and dump II: 0.1 – 1000 seconds i. “Normal Injection Sequence” started by the LHC sequencer; ii. Pilot beam is injected and adjusted, then the intermediate beam is over-injected (in this case the pilot is deflected onto the TDI) and adjusted; iii. Once both rings of the machine are judged satisfactory with the intermediate beam, the Injection Sequence is launched; iv. Via the sequencer, generate and issue a timing event which is received by the BIS and triggers the beam dump for both rings by opening the beam permit loop; v. No “request PM” event is issued. The timing system generates a “request XPOC” timing event, after receiving a dump request associated with a “request dump” timing event while in “Inject and Dump II” mode – OR – specific shot-by-shot transient data logging data is acquired, associated with the injection and with the beam dump. vi. The XPOC process inhibits the injection by the SW user permit channel of the BIS vii. The data required for the XPOC is transferred to the servers and analysed by the XPOC process; viii. If the dump action was correctly executed the XPOC process gives the user permit; ix. The BIS makes an automatic reset, possible for “Normal Injection” Machine Mode; x. The sequencer launches the “arm LBDS” sub-sequence; xi. Inject a pilot bunch into Ring 1 and Ring 2; xii. Change to nominal beam in the SPS; xiii. Start injecting the nominal beam, over-injecting the pilots in Ring 1 and Ring 2;

Dump of both beams at end-of-fill i. Machine mode is set to “Unstable Beams”/”Adjust” by the LHC sequencer; ii. Preparatory steps executed by the LHC sequencer for machine, experiments, beam; iii. Generate and issue timing event(s) which is received by the BIS and triggers the beam dump for both rings by opening the beam permit loops; iv. The timing system generates a “request PM” timing event, after receiving a dump request associated with a “request dump” timing event. Possibly the specific shot-by-shot transient data logging data is still acquired, associated with the beam dump, depending on details of the XPOC data acquisition; v. The XPOC process inhibits the SW user permit channel of the BIS vi. The data required for the XPOC is transferred to the servers and analysed by the XPOC process; vii. If the dump action was correctly executed the XPOC process gives the user permit; viii. The BIS does NOT make an automatic reset;

Dump of one beam i. Machine mode is set to “Unstable Beams”/”Adjust/???” by the LHC sequencer; ii. Preparatory steps executed by the LHC sequencer (?); iii. Generate and issue timing event(s) which is received by the BIS and triggers the beam dump for one rings by opening the beam permit loop; • The timing system DOES NOT generates a “request PM” timing event. Possibly the specific shot-by-shot transient data logging data is still acquired, associated with the beam dump, depending on details of the XPOC data acquisition. • The XPOC process inhibits the SW user permit channel of the BIS for the appropriate beam; vi. The data required for the XPOC is transferred to the servers and analysed by the XPOC process; vii. If the dump action was correctly executed the XPOC process gives the user permit; viii. The BIS does NOT make an automatic reset;

Programmed dumps (incl. inject & dump)