1
|
- “Progress” from my last BENE talk (May’04) until now.
|
2
|
- 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
|
3
|
- 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!
|
4
|
- 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
|
5
|
- In this lattice, we had some success
- Grahame’s original gets 1.695%
- Optimised version gets 2.277% (34% higher)
- These are m+/p+ so 1.64, 2.20 ×10-3m+/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. *
|
6
|
- 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”
|
7
|
|
8
|
|
9
|
- 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
|
10
|
|
11
|
|
12
|
- 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
|
13
|
|
14
|
- The optimisation of the chicane design has not yet generated anything
better than the baseline (although the baseline was not given as input
data)
|
15
|
- 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, s=24.3
- At 2% this gives 1200 out, s=34.3
- Could even be a factor of sqrt(3) larger
|
16
|
- This produces difficulty for an optimiser when occasional +3s 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
|
17
|
- But we see quite regular progress!
|
18
|
- 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
|
19
|
- 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.
|
20
|
- 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…
|
21
|
- 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
|
22
|
- It becomes possible to generate datasets for a variety of energies:
|
23
|
- 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 m/p.GeV
- (With all these I should keep in mind how much data I really want Muon1
users downloading from the website…)
|
24
|
- The code seems to produce too many p-, 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 p+…
|
25
|
- 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
|
26
|
- 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?)
|
27
|
- 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
|
28
|
- A gap (unwise!)
- Widening or narrowing solenoids (inconvenient)
- Rerouting the solenoid coils (weird, but maybe possible)
|
29
|
- 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:
|
30
|
- 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 ds/dDE table
as a reference to benchmark practical tracking techniques against
|