stephen brooks / ral / november 2004 optimisation of the ral muon front end design “progress”...

Stephen Brooks / RAL / November 2004

Optimisation of the RAL Muon Front End Design

“Progress” from my last BENE talk (May’04) until now.


Contents

• The two new optimisations this summer– Partial progress in phase rotation– But some issues are limiting the optimiser

• Beginning to use the MARS code– Nearly ready to break away from 2.2GeV

• What to do with 3MW of protons?– You can’t just ignore them (so some ideas)

• Some news from Oxford particle physics


Disclaimer

• This talk is a collection of unrelated pieces and must in no way be interpreted as a cohesive body of research fit for any particular purpose!


ChicaneLinacB and PhaseRotB

• Two new designs began optimisation in May– Decay channel – Chicane – Linac (400MeV)– Decay channel – Phase rotation (180±23MeV)

• The second of these allows a cooling ring


PhaseRotB

• In this lattice, we had some success– Grahame’s original gets 1.695%– Optimised version gets 2.277% (34% higher)– These are +/+ so 1.64, 2.20 ×10-3+/p.GeV

• This is obtained by varying drift lengths, solenoid fields, radii and lengths, RF phases and voltages, the rod Z position, rod angle and numbers of cells.


PhaseRotB ‘optimal’ design• Drifts (not very exciting)

– All drifts in both sections remained near the minimum length (0.5m), apart from:

– Decay channel D2 which is 0.55m, possibly for matching

– Phase rotation drifts PD1, PD2 which are 0.834m and 0.618m

– PD1 includes last chicane drift– RF cavities are within these “drifts”


PhaseRotB ‘optimal’ designDecay channel solenoids

0

5

10

15

20

25

Tes

la

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

met

res Field (Tesla)

Length (m)

Radius (m)

Everything maximal or fixed, apart from ringed points.


PhaseRotB ‘optimal’ design

Phase rotation solenoids

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Tes

la

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

met

res Field (Tesla)

Length (m)

Here, fields are still maximal but solenoid lengths are minimal.


PhaseRotB ‘optimal’ design• RF cavities

– Optimiser increased their number from 30 to 40 (the maximum)

– Required to rotate the drifted muons into an energy window of 180±23 MeV

– We needn’t expect the optimiser to make them any more ‘regular’ than necessary to get as many as possible into that window

0

200000

400000

600000

800000

1000000

1200000

1400000

PRF1

PRF4

PRF7

PRF10

PRF13

PRF16

PRF19

PRF22

PRF25

PRF28

PRF31

PRF34

PRF37

PRF40

Vo

lta

ge

-2.5

-2

-1.5

-1

-0.5

0

Ra

dia

ns

ph

as

e (f

rom

pea

k)

Voltage

Phase


PhaseRotB ‘optimal’ designPhase rotation RF cavity parameters

-2.5

-2

-1.5

-1

-0.5

0

0 200000 400000 600000 800000 1000000 1200000 1400000

Voltage

Ph

ase

(rad

ian

s fr

om

pea

k)

Grahame had 30 cavities (at -90°) instead 40, but with 2.25MV on each! >>>

The line is -90°: there is a bias towards net deceleration


PhaseRotB output phase space

• Original design:



• Grahame’s linearly-designed lattice seems to accelerate the particles slightly too much in the Muon1 simulation

• This could be due to the particles arriving at the RF cavities late because of path-length effects– “Spherical aberration”– Note that Muon1 does RF phasing relative to

the on-axis particle



• New design:


ChicaneLinacB

• The optimisation of the chicane design has not yet generated anything better than the baseline (although the baseline was not given as input data)

• The best score appears 8% higher but this is statistical: it is more like 4% lower


Barriers to optimisation

• With yields so low (~1-2%), there is a lot of noise in the figure of merit

• One simulation has ~20k particles to start with, becoming ~60k with multiple decays and emission delays

• At 1% this gives 600 out, =24.3

• At 2% this gives 1200 out, =34.3

• Could even be a factor of sqrt(3) larger



• This produces difficulty for an optimiser when occasional +3 results get read

• However, the optimisation has definitely been progressing regardless of this– I.e. the ‘improvement’ is not just noise on the

same result

• This is because noise on the same result would cause successive record scores at geometrically increasing times



• But we see quite regular progress!

PhaseRotB broke its previous best more than once per week



• This doesn’t mean that the optimiser hasn’t been hampered by the noise

• Perhaps the ‘flattening’ of the curve and subsequent slow convergence are signs


Sources of stochastic noise

Some things are controlled by the RNG:

• The 20k pions of the initial rod dataset

• Rotations of these pions about the axis

• Random delays of this dataset to simulate 1ns RMS incoming proton pulse *

• Decays of pions and muons ** These are weighted, so they each happen 3x

in the current simulations. Old simulations had the decay 10x and no delays.


Sources of stochastic noise

• Fixing a random seed is not the answer, as this will bias the results!

• Increasing the number of particles would be good, but does it counter the decrease in number of designs tested?

Perhaps something cleverer is possible to make the merit function more continuous, discuss…


Nikolai Mokhov’s MARS code

• MARS version 15.04 has just been installed at RAL

• This is more accurate than the original code (LAHET) used to generate my pion dataset and will scale better to higher energies

• It also means I could possibly increase the number of initial pions from 20k to (100?)k


MARS plans• It becomes possible to generate datasets

for a variety of energies:Proton Driver GeVSPL 2.2

34

RAL green-field study 5RAL/ISIS 5MW 6RAL/ISIS 1MW, FNAL linac 8

10RAL/ISR 15

20RAL/PS, JPARC initial 30

40JPARC final 50


MARS plans

• It is also then possible to optimise the proton driver energy jointly with the rest of the lattice, if we are only interested in which option can give the best /p.GeV

• (With all these I should keep in mind how much data I really want Muon1 users downloading from the website…)


MARS problems

• The code seems to produce too many -, particularly at low energies– This could be my error, or an error in the code

itself, or a mislabelling of particle IDs 3 and 4 at some stage, or a real effect

• Has anyone else found they have at least twice as many negative as positive pions coming out of their target?!

• Intuitively the excess should be of +…


MARS results

• Energy deposition histograms are possible and will later become input for Roger Bennett’s target shock studies

• Preliminary: 1cm radius tantalum rod, 20cm long, with 6GeV proton beam


The 3MW of used proton beam

• Some engineering cross-sections of the target area show where the proton beam can leave and be dumped

• However, some of these have solenoids with coils only on the “convenient” side!

• The mercury jet target is sometimes drawn with the beam dumped in the mercury pool (but why make it more radioactive than is really necessary?)


The 3MW of used proton beam

• One awkward issue is that most optimisation studies have shown a small angle (~0.1rad) is best for pion production

• But in my optimisations the optimal angle seems to be near zero!

• This could be because the other studies have looked at the pion yield closer to the target and not downstream.

• Tilting the rod could give a higher initial yield but with a larger emittance


Solutions with a tilted beam

• A gap (unwise!)

• Widening or narrowing solenoids (inconvenient)

• Rerouting the solenoid coils (weird, but maybe possible)


Solution with an on-axis beam

• Conventionally, the trouble with this has been that the protons go down the muon beamline

• But the chicane design, for example, has a dipole at the end of the decay channel:


And finally…• Oxford’s particle physics department have

been doing studies into first-principles calculation of muon cross-sections in LH2

• These include atomic and molecular energy levels, so the model is entirely self-consistent

• Results will soon be published and I am hoping to use the d/dE table as a reference to benchmark practical tracking techniques against

stephen brooks / ral / november 2004 optimisation of the ral muon front end design “progress”...

Documents