Transcript BDS Alignment, Tuning, Feedback update and Integrated

BDS Alignment, Tuning,
Feedback update and
Integrated Simulation Plans
Glen White
Overview
• Current status of BDS beam dynamics
studies:
– Alignment & tuning
– Intra-train feedback (single pulse studies)
– 5 Hz feedback
• Integrated Uber-Simulation plans
BDS Alignment & Tuning
• Assumptions for hardware:
– All quads,sext’s and oct’s on x and y movers with 50nm
resolution. (Maybe also roll needed for some sext’s)
– All quads,sext, oct’s have x and y dipole corrector windings for
steering.
• Reminder of current strategy:
– Align quads with sext/oct’s deactivated
• Use nulling quad-shunting to get BPM alignment.
• Use global steering algorithm using movers to align to BPM
readouts.
– Get Sext/oct -> BPM alignment by fits to x and y moves.
– Switch on sext/oct’s, moved to established orbit.
– Use 1-1 steering to maintain orbit with low gain, tuned to keep
beam within IP feedback capture range (~<200um).
• Possible using simplistic feedback and 50 pulse convergence gain.
• Eventually optimise with more sophisticated FB.
– Use orthogonal sext moves and skew quad k changes to tune
out linear IP aberrations.
Multi-Seed Results
3
2.2
2.5
 y ( nominal)
1.8
1.6
2
*
 y ( nominal)
2
data 1
x median
y median
1.4
1.5
1.2
2
3
4
5
6
 ( nominal)
7
8
9
1
1
1.1
x
• Lumi-tuned (left)
• Measurement-tuned (right).
1.2
1.3
*
 (
x
1.4
nominal)
1.5
1.6
1.7
Multi-Seed Results
80

70
y
 (normal-mode)
y
60
50
40
30
20
10
0
0
1
2
3
4
5
6
• Normalised vertical emittance growth for measurement-tuned
results.
• Unlike lumi-tuned results, normal-mode emittance growth now also
considerable -> introducing higher-order aberrations which need to
be tuned out also.
BDS Tuning Questions
• What results do I aim for, what do I need to show (for
RDR)?
– Show X % of seeds perform better than Y?
– What is X? 100%? …
– What is Y? ie figure of merit
• Luminosity? Geometric, or real using Guinea-Pig (integrated
simulations…)
• Emittance? What is the emittance budget for BDS system? Me to
provide, or given from LINAC&RTML performance?
• For RDR, need to demonstrate performance on all
parameter sets, both BCD beamlines?? Or enough to
show, e.g. nominal parameter set with IR-1 (20mrad
crossing angle)?
• Can I assume getting movers and dipoles on all magnets
or need to prove that I require these?
BDS Tuning Future Directions
• Immediately, need to get better multi-seed
results.
• From then depends upon suggested priorities
between this, feedback and integrated
simulation construction. ie:
– Make more dynamic, including GM, component jitter
etc…
• May need better 5 Hz feedback
– Include other beam, and lumi simulations (guinea-pig)
– Put more effort into eeking out every last drop of lumi,
better FB, higher-order knobs etc…
BDS Intra-Train Feedback Layout
• 3 independent bunch-bunch beam-based FB
systems in BDS:
– post-LINAC Fast Feeback
• 2 pairs of kickers/BPMs at different phases
• With current optics, need strong kickers (~100 times Voltage
of other 2 FB kickers if same type)
• Also, need ~100nm resolution on BPM’s, ie. Need cavities
• Live with this, or request optics re-design to provide larger
beta-functions?
• Corrects static & dynamic HOM-driven initial wiggle in train +
any other systematic intra-train effects.
• Separates BDS and LINAC 5-Hz feedback systems.
• Not much simulation done with this, makes negligible
difference to luminosity performance with the single pulse
studies done if keep gain low.
BDS Intra-Train Feedback Layout
– IP-ANGLE Fast Feedback
• Corrects and optimises collision angle of bunches
• 3 1m Stripline kickers at IP phase at start of FFS with same
drive requirements as IP FFB.
• BPM 90o downstream.
• BPM res. Required ~ 2um (stripline)
• If not at correct location, or if lattice errors present, cross-talk
to IP-POSITION FFB possible. Can mitigate by reducing
gain, or interleaving- how to spec?
• Assuming this and not a vertical crab-cavity to do angle
correction, can’t see a very good reason that a crab-cavity
solution would be worth the extra complexity even if it were
plausible… or….?
– IP-POSITION Fast Feedback
• Essential- puts beams into collision at IP.
• Based on beam-beam kick signal calculated with
GP.
• BPM just upstream of BeamCal, ~10um res
required (stripline)
• Kicker probably needs to be in the 1m gap between
SD0 and QF1, otherwise is limiting aperture in
magnet.
• Stripline kicker in cold a problem??
• A.S. looked at effect of putting kick upstream of
SD0: no effect up to a 70 sigma kick at upstream
face of SD0, or up to 10 sigma at QF1 downstreamface. 2% vertical beam size growth at 150 sigma
kick at SD0 and 50 sigma at QF1.
• Kick voltage requirements: 600 V/m for 70 sigma
kick for 20 mrad crossing or 3 KV/m for 2 mrad due
to larger aperture.
• IP FFB sets tolerance for 5-Hz feedback- must keep
beam in IP FFB dynamic range. Tail of beam-beam
vs. offset curve goes out to 100’s of nm, but prefer
to be on left-side of peak for fastest convergence.
For nominal beam parameter set, this is ~100nm,
most constricting is low Q parameter set (~35nm).
Vertical beam-beam kick / urad
BDS Intra-Train Feedback Layout
300
250
200
150
100
50
0
0
10
20
30
40
*
y / 
y
Beam-beam kick vs. offset: Blue: TESLA; Green: USSC;
Red: nominal; cyan: Low Q; Magenta: Large Y; Black:
Low P; Yellow: High Lum.
BDS Intra-Train Feedback Layout
• Lumi Feedback
-4.5
1.1
-3.5
1
-2.5
0.9
y' (nm)
– After some number of bunches (~150)
when effects like HOM’s have damped
and beam-based FFB’s have settled,
optimize IP collision parameters using
lumi-based signal.
– Require prompt signal from 1st layer of
BeamCal (integral of incident pairs),
which although not directly proportional to
lumi, are maximal at lumi max.
– Need to perform 2D scan in y,y’ space to
find optimal collision parameters, 2 1D
scans doesn’t give best performance.
– Variables are; size of 2D ‘pixel’ when
scanning and number of bunches to
average lumi signal over for each scan
point. These depend upon noise in lumi
signal and noise characteristics of
incoming beam
– Bunch-bunch system essential if optimal
collision parameters change pulse-pulse
(20% lumi-loss otherwise).
-1.5
-0.5
0.8
0.5
0.7
1.5
0.6
2.5
0.5
3.5
0.4
4.5
-27
-21
-15
-9
-3
3
9
15
21
27
y (rad)
Fast Feedback Study Results
• 200-seed study, including tracking through
LINAC, BDS and IP. Using Placet, MatMerlin
and GUINEA-PIG.
• Study response and performance of FFB’s as
described given initially tuned beamline that
delivers target emittances and lumi. Then add
inter-pulse effects of GM + component jitter
including SR + LR WF’s in Linac cavities.
• TESLA beam parameters used in simulation as
high vertical IP disruption provides most
challenging case for Fast Feedback.
Fast Feedback Study Results
•
•
•
Irreducible 3% loss due to bunch-shape and emittance growth.
2 % loss due to gain of FB amplifying random bunch-bunch jitter. Can be mitigated by reducing
gain after lumi-optimisation if expect no further intra-train dynamics after this point.
Further 3% loss due to initial HOM-driven instability, settling time of feedbacks and time taken to
perform collision optimisations. Can look into partially mitigating this loss by using more
aggressive initial feedback technique, reducing number of sample per lumi scan point (here, 5) or
increasing pixel size of 2D scan. These are greatly dependent on the precise noise characteristics
of the incoming beam however.
40
1/N dn/dL
30
= 0.95  = 0.01
1
Lmax  =0.97  = 0.01
0.9
L
plat
L =0.92  =0.01
Lumi / max possible Lumi
35
25
20
15
10
5
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0
0.8
0.85
0.9
0.95
Luminosity / Max. Achievable
1
100
200
300
Bunch #
400
Fast Feedback Questions
• Assume the 3 beam-based FFB’s operate independently.
If conditions prevail that makes this not the case, can
improve independence by reducing gains, or
interleaving. Has lumi consequences- will be an
operational optimization at time of ILC running. Any
numbers required now on trade-offs on different
schemes?
• Want to look into any other fast feedbacks?
• What other effects important to put into simulation?
–
–
–
–
Collimator wakes.
Fast RF instabilities.
Bunch charge fluctuations.
More intra-train dynamics, e.g. from DR extraction (currently
assuming flat-insertion). -> model turn-around FFB? Include
RTML studies -> integrated simulations…
– Again, need to study all parameter sets/crossing schemes etc. ?
5-Hz Feedback
• Requirements- keep emittance growth small and
beam within IP FFB capture range.
• For alignment study purposes, 1-1 correction
with every magnet corrector and BPM and ‘IP
BPM’ (beam-beam kick) with low gain (50-bunch
convergence) seems adequate.
• Is this still adequate with ground motion?
• At least probably want to make informed
selection of correctors/BPM’s to use, especially
when considering E errors…
The Mother of all Simulations
• Integrated feedback plans.
• Construct framework to include all beam
dynamics simulations from DR exit ->
RTML -> LINAC -> BDS -> IP ->
extraction.
• I’m using Lucretia.
• Goal to produce multi-seed averaged
luminosity vs. time plot including all
alignment, tuning and feedbacks.
Integrated Feedback Strategy
•
•
Doing everything, linearly with multi-bunches the whole way will be way too
slow.
One approach:
– Produce ~100 seeds of aligned & tuned RTML, LINAC and BDS files.
– Randomly load one in of each for each seed (and wakes etc…).
– With single seed tracking, advance to time N including 5-Hz feedback applied
every Mth pulse throughout.
– Then track multi-bunch and get Lumi estimate.
– Repeat for desired length of time, perform retuning where necessary.
•
Estimate of CPU requirements:
– ~10 mins per single bunch track, ~30 hours per multi-bunch simulation with lumi
estimate on the newest type of CPU’s currently found in compute clusters.
– Assuming from TESLA TDR studies, need to re-tune on 10-day type timescaleswant to study ~30 days of ILC-time.
– If choose N= once per day and M=every 30 mins and want 100 seeds, this is 475
days of cpu time! (for one machine configuration and one of the beam parameter
sets).
– Assume availability of 100 cpu’s for this task- just over a month of time to
complete (checkpointing of simulation important as each parallel task to run
longer than the cpu time limit on cluster schedulers).
– To get it done faster than this will require parts of the simulation to be internally
parallelized (parallel tracking algorithms, parallel GUINEA-PIG). Even then, not
clear that running 100 parallelized simulations sequentially will be better than 100
simultaneous runs of the whole simulation, unless we get LOADS of CPU’s and
do both!