Colliding beams and optimizing luminosity
Download
1 / 11

Colliding Beams and Optimizing Luminosity - PowerPoint PPT Presentation


  • 114 Views
  • Uploaded on

Colliding Beams and Optimizing Luminosity. S. White, H. Burkhardt, LBS#4 , 27 May 2009. Commissioning and parameters: http://lhccwg.web.cern.ch/lhccwg and http://lhc-commissioning.web.cern.ch 2008 commissioning procedures - remain valid 2009 / 2010 run :

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Colliding Beams and Optimizing Luminosity' - rhea


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Colliding beams and optimizing luminosity
Colliding Beams and Optimizing Luminosity

S. White, H. Burkhardt, LBS#4 , 27 May 2009

Commissioning and parameters:

http://lhccwg.web.cern.ch/lhccwg and http://lhc-commissioning.web.cern.ch

2008 commissioning procedures - remain valid

2009 / 2010 run :

Chamonix 2009 with W. Herr Options and preferences for proton runningslides and in proceedings

Earlier presentation (H. Burkhardt): LHCCWG 06/09/2006

Luminosity, Van Der Meer Scans:

BE-OP Group:

wikis LHCOPSeparation scans

LHC Reports:

H. Burkhardt, P. Grafstrom, Absolute Luminosity from Machine Parameters , LHC Project Report 1019

S. White, R. Alemany Fernandez, H. Burkhardt, M. Lamont, Luminosity Optimization and calibration in the LHC, PAC09 proceedings


Ip bumps
IP-bumps

MCBX in triplet - important for crossing

angle and aperture at injection. Act on both

Beams and planes at the same time.

collapse bump by combination of

MCBC, MCBY and MCBX

or ramp down MCBX first

Separation scans, optimization with

MCBC, MCBY on one beam

  • Bringing the beams into collision consist of ramping down the magnets to zero field. The time to go into collision is given by the slowest magnet. The two beams will move together because of the MCBX. Detailed presentation given at the LBC on 21/04/2009.

  • Hardware tests are foreseen this summer to measurement the real performances of these magnets and determine the time to go into collision.

How (and why) do we use MCBX for crossing angles and separation bumps slides by W. Herr LCU meeting 21/04/2009


Get lhc beams colliding bpm resolution
Get LHC beams colliding : BPM resolution

measured with special (beam-) directional stripline couplers BPMSW

at about 21 m L/R from IP in front of Q1, 2 each in IR

adjust orbits such, that the beam 1 and 2 difference left/right of the IP is the same

beams must then collide. This is independent of mechanical offsets and crossing angles

Luminosity reduction with separation

Beam sizes at the IP @ 5 TeV

Both beams move with MCBX : First collapse the separation bumps and then optimize with BPMs.

Expected resolution for small separation and 0 crossing angle ; in each plane.

~ 50 μm: using selected, paired electronics ; otherwise ~ 100 - 200 μm

beam 1 and beam 2 have separate electronics

~ 10 μm: with extra BPMWF button pick-ups. Installed in 1&5, for large bunch spacing, EDMS doc

976179

3


Crossing angle and parasitic beam beam
Crossing angle and parasitic beam-beam

Nominal LHC with collisions in IP1&5

Can be completely avoided up to 156 bunches

Then gradually becoming an issue

would be good to gain first experience on this

in the 2009 / 2010 run

Nominal, IP1/5 : each 30 parasitic collisions ~ 9σ

Parasitic b.b. effects reduce with fewer bunches

or increased crossing angle

Simulation : IP5 colliding. IP1 going into collision by ramping down the horizontal separation

close to head on beam-beam :

peaks in blow up at 0.5 and 1.5 σ

Some ref.

W. Herr, M. Zorzano LHC Project Report 462 ; Tatiana Pieloni thesis

Figures above from S. M. White, H. Burkhardt, S. Fartoukh, T. Pieloni,Optimization of the LHC Separation Bumps Including Beam-Beam Effects WE6PFP018, PAC’09


Luminosity background lifetime
Luminosity, Background, Lifetime

  • Going into collisions :

  • initially, probably also later for every step in commissioning towards higher intensity/luminosity

  • one experiment at a time + measure / tune

  • interesting for background to distinguish between main sources

  • collisions related

  • beam gas

  • halo

  • General sequence :

  • injection, ramp, squeeze - adjust tune, orbit, chromaticity .. ➞ Pre-collision

  • If lifetime ok, experiments could consider to start taking data

  • Collapse separation - measure and optimize if needed

  • Separation scans to centre collisions - when and how often - to be seen

  • On demand : larger separation scans to calibrate luminosity


The van der meer method
The Van Der Meer Method

Aeff = 4psxsy

Beam intensities and revolution frequency are known with good accuracy. The effective overlap

area can be determined by scans in separation..

Planned: orthogonal x/y scans. Example of LEP:

~ 5 minutes/IP.

Separation scans in the LHC should allow for reliable beam size measurements at the IPs.

X-axis : absolute length scale from bump (and BPM) calibration (response matrix analysis)

Y-axis : any relative Luminosity LHC-BRAN, ATLAS-LUCID, CMS-HF, ...


Some beam parameters
Some beam parameters

Beam-Beam Effects

LHC round beams, const εN

Beam-beam tune shift parameter ξ

for head-on collisions

depends on intensity

( not energy, β* )

At the design emittance:

Crossing Angle

Hour Glass Effect

Calibration Scan Beam Parameters

  • Adjust beam parameters to minimize all

  • unwanted effects. The calibration scans

  • will take place during dedicated runs:

  • No crossing angle (up to 156 bunches)

  • Moderate intensity ~ 5x1010 p/bunch

  • large β* ~2-11m

  • Even with these parameters counting rates would be sufficient to get below 1%

  • statistical accuracy within a few seconds.

where

for nominal σz = 7.55 cm

5 TeV. Lumi reduction by

±142.5μrad crossing angle


Systematic effects and uncertainties
Systematic effects and uncertainties

  • Relative monitoring precision and statistical errors are not expected to be an issue

  • Beam parameters set so that all the effects presented before are negligible.

  • Intensity : measured with Beam Current Transformers BCT. Fast monitors 1-2% precision. Total current, absolute measurement, most precisely measured with DC monitor. Make sure there are no unknown longitudinal / transverse tails with a calibration at the end of the ramp where the

  • beams are fully bunched.

  • Bunch by bunch variations no crossing angle : maximum 156 bunches - no parasitic beam-beam all bunches in a beam travel on the same orbit bunch dimensions and intensities can be different - just sum up correctly in simplest case total N2 = Σ n11 n21 + n12 n22 + n13 n23 +...

  • Easy for ATLAS and CMS b1i collides with b2i. Not the case for ALICE and LHCb.

  • Requires careful bunch to bunch analysis.

  • Non Gaussian transverse beam shape can add errors of a few percent (learn with experience).

  • All machine measurements should be cross checked with independent experiment measurements if possible. Example: Length scale calibration with experiments measurements of the luminous region from tracks reconstruction.

  • We expect that precision of 10% on the absolute luminosity measurement can be reached in the LHC. Previously achieved at RHIC.


Experience from rhic
Experience from RHIC

  • The Van Der Meer (or Vernier) scans are extensively used at RHIC for luminosity calibration and optimization.

  • Optimization scan: included in the feedback system, fast scans performed several times during a fill, sometimes several IPs at once.

  • Calibration scan: end of the fill, one IP at the time, input parameters on experiments request.

Data from the 2009 250 GeV pp run

Data taken during a

scan in PHENIX in

the horizontal plane.

In this example each

step point represents

an acquisition time

of 1 minute.

  • Comparison between several detectors.

  • In black a Gaussian fit on the ZDC data

  • Non-Gaussian tails.

  • Measured separation versus the

  • Magnet settings.

  • Coupling between the planes.

  • It is important to cross check all the measurements to determine the sources of errors and determine

  • the systematics.


Application software
Application Software

Luminosity Scan Application

  • A dedicated software in the java framework has been developed

  • to perform scans for optimization or calibration. Angle scans are

  • also possible. EDMS doc. 894460

  • Fully automated or manual.

  • The number of steps, integration time are input parameters and

  • can be changed on request.

  • The data are to be stored in a database. EDMS doc. 970037

Data Validity

  • The application continuously monitors the power convertors state in order to check if the beams are moving.

  • Only the data acquired while the beams are idle are valid.

  • A flag is sent via DIP for the experiment to monitor the power convertors state. The power convertors state is know to a precision of 0.5 s.

  • Throw the first and last second of each scan step.


Data exchange
Data Exchange

  • All the data will be exchange online via DIP the publication can be found under

  • dip/acc/LHC/Beam/LuminosityScan (K. Kostro) and contains:

  • Plane [string] : X or Y, IP number [int], Scan status [string], Nominal separation [double], Data Acquisition flag [boolean], Time Stamp [long] : UTC time.

  • Successful tests were performed last year with CMS (V. Halyo, J. Werner) HF detector, and ATLAS (D. Caforio, A. Sbrizzi et al.), LUCID, ZDC, BCM.

  • Data exchange with ALICE and LHCb still remains to be tested.

  • The purpose of online data exchange is to check the validity of the measurement: no detailed analysis will be done online.

  • Continuously publishing (~1Hz) one relevant number (event rate, luminosity…) per detector during the scan should be sufficient.

  • To determined by the experiment.

  • No handshake foreseen during the scan.

  • Detailed information (bunch to bunch, background…) are to be stored in an accessible database for offline analysis.

  • Proposal for DIP publication structure:

  • dip/experiment name/detector name/Luminosity


ad