CERN Accelerating science

This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.

Injection - beam request

Boundary conditions

Nominal Sequence

  1. Pilot R1
  2. Pilot R2
  3. Over inject intermediate R1 & optimise
  4. Over inject intermediate R2 & optimise
  5. Dump intermediate R1
  6. Inject pilot R1
  7. Dump intermediate R2
  8. Inject pilot R2
  9. Over inject batch 1 of nominal etc. - continue with interleafed injection

Use Case - variations

See also timing  and RF

We will need an INJECTION SEQUENCE to be configured before the process is started. Set-up offline, this will drive the pre-loading of equipment settings and timing. And some of the checks to be performed before injection begins. It will then be used to sequence the requested injection sequence.  See injection sequencer

CBCM 2009

We will hit the CBCM [Central Beam and Cycle Manager] with:

R1: Information to be sent out in a telegram 
R2: Timing event requests
R3: Other information is also to be distributed.

  1. Ring
  2. Bucket
  3. PS (Booster) user (intensity)
  4. Number of PS batches

There will be the possibility of issuing a injection request for a single shot or to sequence a series of injections.

Central in this discussion is the decision where to install the monitoring and logic deciding the LHC beam destination. 

The CBCM shall received one injection request at a time. It will not be loaded with a pre-defined injection sequence. The dangers of damage are high and the LHC must retain explicit control of the injection sequence. If this means reduced efficiency of the accelerator complex while the LHC is filling - so be it.  (Eventually, when the process is mastered, we might think about having the CBCM choreograph things but it can wait.)

1.5 second SPS descent.  PS RF needs 450 ms pre-warning.  (Target bucket required in PS 50 ms before extraction from the PS for re-phasing.) CBCM will require some time to rebuild the requisite telegram.  Gives us about a 1 second to make our minds up, if we want to use the next cycle. (Bear in mind, that even if the beam is injected into the SPS we have until the next extraction to decide whether or not to take it.)  

What happens if the sequence breaks down? Operations need to be able take manual control. Request repeat or continue or restart etc.

Sequence Outline

1. LHC makes request to CBCM with ring, bucket number, PS user (intensity) and number of PS batches.

2. Beam injected into SPS, accelerated. Beam quality checks on flat top.

3. SPS  - decision to extract or not. Check with LHC.  If yes, lift extraction inhibit [BIC]. CBCM will be sending out warning events to the RF and BI plus incoming beam type. The RF sends out the  the pre-pulses [whether extraction inhibit or not] to kickers.

4. Extraction. Beam down TI2/TI8. [checks on BLMs, trajectory]

5. Injection into LHC - injection kickers received pre-pulses.
BST receives pre-pulse, sends out acquisition event for BPMs, BLMs as required.
Longitudinal feedback, transverse feedback and other settings preloaded to RF. BATCH dependent settings triggered by timing events. RF, essentially will be multiplexing on beam type in each ring independently.

6. Beam quality checks in LHC.  First turn, beam loss, intensity, emittance.

 

Julian Lewis's presentation on the subject

 


MISC

Also specify tolerances on current, emittance etc. set-up parameters for SPS - less dynamic

https://edms.cern.ch/file/393703/3/LHCbeamquality.pdf


RF

 

Philippe Baudrenghein is requesting and expects the bunch number and the destination ring to be delivered to him in SR4 on the LHC timing
wire. This would be delivered every SPS cycle whenever the LHC is in injection mode (mode is another issue). Only when the LHC requests beam
would the MKI fire. All this to be orchestrated by the CBCM and the LSA sequencer.

  1. the destination ring, 
  2. position on the circumference or bucker number (specified how?) - the LHC Injection Index(s). Bucket number(s) will have adjustable value with default setting. SPS phase also needs to be sent. (preloaded - selected by timing events (?))
  3. the SPS cycle type which he uses to indicate the batch type(?) . - confirm the last request. possibly PS user - call this batch description. - not need apparently - PB Nov 2004

The request for this information had been made to the timing working group and the RF team are anticipating that the information be delivered by the timing system.     Right... this comes from the LHC, we have to pass it to the timing system for forwarding.

Longitudinal feedback, transverse feedback and other settings - preloaded. BATCH dependent settings triggered by timing events. [Generate Settings] [Load Settings]

Clearly the events have to be set up in advance.  [Configure Timing Events]

here are the reference to the RF Synchro publications: papers:

http://doc.cern.ch/archive/electronic/cern/preprints/sl/sl-98-027.pdf

http://doc.cern.ch/archive/electronic/cern/preprints/open/open-99-077.pdf


I remind you that our scheme calls for a decision on the chosen LHC bucket 450 ms BEFORE the CPS to SPS transfer. (I was wrong in mentioning 650 ms during our discussion).

PB doc