RFQ GPT Input Beam Distributions Simon Jolly 22 nd August 2012

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

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 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)

22/08/12Simon Jolly, University College London4

Horizontal Acceptance (Old) 22/08/12Simon Jolly, University College London5

Horizontal Acceptance (New) 22/08/12Simon Jolly, University College London6

Vertical Acceptance (Old) 22/08/12Simon Jolly, University College London7

Vertical Acceptance (New) 22/08/12Simon Jolly, University College London8

Emittance Variation (Old) 22/08/12Simon Jolly, University College London9

Emittance Variation (New) 22/08/12Simon Jolly, University College London10

Twiss Parameters: Beta-X (Old) 22/08/12Simon Jolly, University College London11

Twiss Parameters: Beta-X (New) 22/08/12Simon Jolly, University College London12

Twiss Parameters: Beta-Y (Old) 22/08/12Simon Jolly, University College London13

Twiss Parameters: Beta-Y (New) 22/08/12Simon Jolly, University College London14

Twiss Parameters: Alpha-X (Old) 22/08/12Simon Jolly, University College London15

Twiss Parameters: Alpha-X (New) 22/08/12Simon Jolly, University College London16

Twiss Parameters: Alpha-Y (Old) 22/08/12Simon Jolly, University College London17

Twiss Parameters: Alpha-Y (New) 22/08/12Simon Jolly, University College London18

Matched Parameters: Results We now have matched Twiss parameters at the RFQ input datum! –  x = ;  y = –  x = ;  y = 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

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

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

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

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

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

Results: Transmission 22/08/12Simon Jolly, University College London25

Results: 60 mA Transmission 22/08/12Simon Jolly, University College London26

Results: 60 mA Exit Emittance 22/08/12Simon Jolly, University College London27

Results: 60 mA Peak Power Loss 22/08/12Simon Jolly, University College London28

SetZdist: Input Beam 22/08/12Simon Jolly, University College London29

SetZdist+setFile: Input Beam 22/08/12Simon Jolly, University College London30

SetTdist: Input Beam 22/08/12Simon Jolly, University College London31

SetFileSJ1: Input Beam 22/08/12Simon Jolly, University College London32

SetFile: Input Beam 22/08/12Simon Jolly, University College London33

SetFileSJ1: Input Beam 22/08/12Simon Jolly, University College London34

SetTdist: Input Beam 22/08/12Simon Jolly, University College London35

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

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

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

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