Download presentation
Presentation is loading. Please wait.
Published byAlan Snow Modified over 8 years ago
1
RFQ GPT Input Beam Distributions Simon Jolly 22 nd August 2012
2
RFQ Input Beam Matching At the last FETS meeting, I showed the results of taking the matched Twiss parameters at the end of cell 3 and tracking them upstream to the RFQ input datum (upstream face of entrance flange). Lots of variation in input acceptance due to RF phase variation. Alan went back and generated matched parameters at the end of cell 3 for 32 different phases, covering 2 pi of phase in regular steps. I then tracked all of these back upstream at 60 mA, using 2D waterbag distribution and 2Dline spacecharge, to find matched Twiss parameters. 22/08/12Simon Jolly, University College London2
3
RFQ Input Datum A number of small changes to RFQ entrance region: –Rounding off of matching section nose makes radial matcher shorter. –Keeping distance from entrance flange to start of radial matcher the same means distance to end of radial now shorter. The important numbers: –RFQ input datum is outer face of main end flange (not insert). –RFQ input datum is 21 mm from design RFQ input at start of design radial matcher (14 mm thick, 7 mm gap). –RFQ input datum is 42.7698 mm from end of radial matcher. –Nothing downstream of this point has changed… 22/08/12Simon Jolly, University College London3 RFQ Input Datum Design Matcher Real Matcher End of cell 3 (matched parameters)
4
22/08/12Simon Jolly, University College London4
5
Horizontal Acceptance (Old) 22/08/12Simon Jolly, University College London5
6
Horizontal Acceptance (New) 22/08/12Simon Jolly, University College London6
7
Vertical Acceptance (Old) 22/08/12Simon Jolly, University College London7
8
Vertical Acceptance (New) 22/08/12Simon Jolly, University College London8
9
Emittance Variation (Old) 22/08/12Simon Jolly, University College London9
10
Emittance Variation (New) 22/08/12Simon Jolly, University College London10
11
Twiss Parameters: Beta-X (Old) 22/08/12Simon Jolly, University College London11
12
Twiss Parameters: Beta-X (New) 22/08/12Simon Jolly, University College London12
13
Twiss Parameters: Beta-Y (Old) 22/08/12Simon Jolly, University College London13
14
Twiss Parameters: Beta-Y (New) 22/08/12Simon Jolly, University College London14
15
Twiss Parameters: Alpha-X (Old) 22/08/12Simon Jolly, University College London15
16
Twiss Parameters: Alpha-X (New) 22/08/12Simon Jolly, University College London16
17
Twiss Parameters: Alpha-Y (Old) 22/08/12Simon Jolly, University College London17
18
Twiss Parameters: Alpha-Y (New) 22/08/12Simon Jolly, University College London18
19
Matched Parameters: Results We now have matched Twiss parameters at the RFQ input datum! – x = 3.8263; y = 3.4091. – x = 0.15996; y = 0.14152. All phases very similar: much less variation than previously. Alpha’s and Beta’s now converge around a single value. Having sorted the transverse, it’s time to fix the longitudinal… 22/08/12Simon Jolly, University College London19
20
RFQ Input Beam Distribution Since my very first RFQ simulations in GPT, I have been using the same method of starting the beam in GPT: –2D distribution generated using either: Particle distribution from input file (Alan). setWBemittance function with matched emittances/Twiss parameters. –2D “stretched” into 3D by using a GPT setZdist statement: Beam has same transverse dimensions along its length. Beam looks cylindrical in 3D. This distribution is good for the spacecharge simulation – ghost bunches appear the same in front/behind – but BAD for getting the transverse parameters right! Cylindrical beam has correct Twiss parameters only at the start, but back changes dimensions depending on emittance. However, no alternative proposed for previous simulations. Need to make sure we’re getting the right input beam since RFQ transmission seems to be quite sensitive to input conditions. Needed to explore 3 different input methods… 22/08/12Simon Jolly, University College London20
21
1: setZdist Beam started using GPT “setZdist” statement. All beam has same initial dimensions. No discontinuities with space charge. Wrong transverse dimensions: beam arrives in “cone” from last solenoid. Beam too dense by the time rear of bunch enters RFQ. 22/08/12Simon Jolly, University College London21 RFQ start Beam Direction Beam generated backward s from input RFQ start Beam shrinks from emittance Space charge is always right
22
2: setTdist Beam started using GPT “setTdist” statement. Beam always has correct initial dimensions at input datum. Space charge sees discontinuities. Beam created in steps: strange space charge effects. 22/08/12Simon Jolly, University College London22 RFQ start Beam Direction Beam generated forwards from input RFQ start Space charge has discontinuities for first few periods Space charge very strange during beam creation
23
3: setFile Beam started using GPT “setFile” statement. –Create 2D beam distribution using matched parameters. –Track backwards using spacecharge2Dline to get space charge right, creating many 2D slices with screens. –Output beam distribution to Matlab. –Interpolate (x,y,Bx,By,Bz) data from multiple screen data at random z-positions. –Write GDF file to re-input data. Beam always has correct initial dimensions at input datum. Space charge sees discontinuities. 22/08/12Simon Jolly, University College London23 RFQ start Beam Direction Beam loaded in single step Space charge has discontinuities for first few periods
24
Input Simulations: Initial Results Ran usual simulations to check differences between input method: –Transverse waterbag distribution using matched Twiss parameters. –Beam tracked to RFQ output datum to measure transmission. Very odd results: >97% 3 MeV transmission for setZdist and setTdist but only ~88% for setFile: –Results should be very similar! –Most realistic is “setFile”, so why 10% transmission loss…? Had to go on a 2 week detour to find the errors: –Extract cylindrical beam from “setZdist” and reintroduce using “setFile”: results should be identical. –Create my own conical beam distribution (original was from Juergen) to make sure the problem wasn’t with the beam distribution itself. 22/08/12Simon Jolly, University College London24
25
Results: Transmission 22/08/12Simon Jolly, University College London25
26
Results: 60 mA Transmission 22/08/12Simon Jolly, University College London26
27
Results: 60 mA Exit Emittance 22/08/12Simon Jolly, University College London27
28
Results: 60 mA Peak Power Loss 22/08/12Simon Jolly, University College London28
29
SetZdist: Input Beam 22/08/12Simon Jolly, University College London29
30
SetZdist+setFile: Input Beam 22/08/12Simon Jolly, University College London30
31
SetTdist: Input Beam 22/08/12Simon Jolly, University College London31
32
SetFileSJ1: Input Beam 22/08/12Simon Jolly, University College London32
33
SetFile: Input Beam 22/08/12Simon Jolly, University College London33
34
SetFileSJ1: Input Beam 22/08/12Simon Jolly, University College London34
35
SetTdist: Input Beam 22/08/12Simon Jolly, University College London35
36
Conclusions Input distributions results finally make sense: –setZdist gives slightly worse transmission than setFile, which is slightly worse than setTdist. –Methods are virtually identical at 60 mA. –Differences in transmission a result of incorrect beam from Juergen: beta right, alpha wrong (something he has confirmed). After an exhaustive effort, RFQ simulation parameters are now fixed: –Beam started at RFQ input datum. –Transverse waterbag from matched Twiss parameters. –Longitudinal distribution from setTdist. Now for the acceptance… 22/08/12Simon Jolly, University College London36
37
Paper 1: RFQ Integrated Design Paper will cover modelling background for our integrated RFQ design method. This is mainly RFQSIM -> Inventor -> Comsol -> GPT -> Matlab, but also includes sections on bulk CAD design and electromagnetic/thermal simulations. Half written: just waiting for other people to fill in some sections: –Introduction –*Vane Modulation Parameter Generation (APL – RFQSIM) –*RFQ Mechanical Design (PJS) –Vane Tip Modulation CAD Design (SJ) –*Electromagnetic Cavity Simulations (SL) –*Thermal Modelling (SL) –Beam Dynamics Simulations (SJ) Field Mapping (SJ - Comsol) Particle Tracking in GPT (SJ) –Conclusions (SJ) 22/08/12Simon Jolly, University College London37
38
Paper 2: FETS RFQ Design Paper will cover all steps we went through to design FETS RFQ. Will refer to previous integrated design paper, so no need to describe methods again, but needs to include all information showing how much work we’ve done on the various aspects of the design. I will take as much as I can from the conference papers, but will need help filling in gaps as there are several things that have been presented at FETS meetings I couldn’t find in PAC/EPAC papers. Outline will be similar: –Initial parameter generation and design limitations (APL + RF/klystron) –Basic CAD design (PJS) –Cold model construction and bead pull (SJ/PJS) –Electromagnetic cavity simulations (SL) –Thermal simulations and squirt nozzle/cooling design (SL/PJS) –Vane tip CAD modelling (SJ) –Beam dynamics simulations, inc RFQSIM/CAD modelling comparison (SJ) –Final CAD design, including tuner design, RF feedthroughs etc and final RFQ parameter comparison (SJ/PJS/APL) –Anything else… As Juergen suggested, this paper should include everything but also refer to conference papers… 22/08/12Simon Jolly, University College London38
39
Paper 3: Fringe Fields/Tolerances Paper will cover all the “edge effects” that have come largely from the CAD modelling. Try to show how really starts to interfere on some of the “optimised” areas of the RFQ design. Juergen’s work on the effect on the beam energy spread from the matching section fringe field: I will run some simulations (suggestions please…). All the simulations I’ve done recently checking the alignment and machining tolerances. 22/08/12Simon Jolly, University College London39
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.