IK March 1st 2012 Slide 0 EMMA: Update on BPM modelling and mapping March 1 st 2012 Ian Kirkman

IK March 1st 2012 Brief reprise of need for mapping of EMMA BPMs Slide 1 Electrode response does not vary linearly with distance to beam Response is a function of the BPM geometry and materials Cannot use 4-button responses to simply deduce beam position – errors of up to > 5mm in recovered beam position can arise Therefore the particular BPM response needs first to be measured or modelled

IK March 1st 2012 Measuring and Modelling the EMMA BPMs (2010 onwards) Slide 2 Bench tests Theory Electrostatic (2-D) CST (3-D) Four approaches essentially used to confirm the reliability of the CST method. CST data then used for all further modelling.

First look was in early 2010: A 7 th order polynomial based mapping function used to cover entire (Xunc, Yunc) space More points added for cylindrical 2011/12 : Essentially a 4mm grid adopted over area of approx. linearity But points get denser points as beam moves away towards the beampipe edges Too few points modelled for rectangular BPM assembly – needs more Use of new “local fit” method appears to necessitate a finer mesh of modelled points – in progress. IK March 1st 2012 Status of CST modelling Slide 3

IK March 1st 2012 Some details of CST modelling Slide 4 Particle Studio used (identical results obtained with e.g. EM Studio) DC system assumed (confirmed okay through bench tests) Full double BPM beampipe assembly modelled “as one” in 3-D “Cylindrical” and “Tapered Cylindrical” assemblies give subtly different results CST does not use paging memory – so limited by RAM of machine (few Gbytes) Approximately 5 million hexagonal meshcells modelled, with automatic mesh generation If uniform mesh, mesh cell ~ 400 um on a side, but actually much smaller where model requires it for specified 1 in 10^6 accuracy Each point takes approximately 1 hour to run Cannot set up batch runs – limited user licence server – frowned upon

IK March 1st 2012 Use of modelled data for subsequent mapping Slide 5 Xunc Yunc Xunc Yunc [Alex. Kalinin] The values of Xunc and Yunc are then used in the mapping to recover the Xreal, Yreal values

IK March 1st 2012 CST data for Xreal vs (Xunc, Yunc ) – Cylindrical BPM Slide 6

IK March 1st 2012 CST data for Yreal vs (Xunc, Yunc) – Cylindrical BPM Slide 7

We assume the bunch charge is proportional to the sum of the 4 electrode responses (see, for example, “Charge, position and resolution computing in EMMA BPMs”, Alex. Kalinin, EMMA meeting, ) Suppose a bunch at the beam centre gives ∑Vi = 1 The same bunch situated close to an electrode would give ∑Vi >> 1 Therefore, we cannot simply use ∑Vi as a measure of the charge (or variation of charge) in the circulating bunch Approach adopted is to simulate a unity charge at a variety of x and y positions, then to provide a normalisation value, Qf, which must be divided into ∑Vi at any beam location to derive the bunch charge which would have been measured if the beam had been at the centre of the beampipe See following figures IK March 1st 2012 Charge Normalisation Factor, Qf Slide 8

IK March 1st 2012 CST data for Qf vs (Xunc, Yunc) – Cylindrical BPM Slide 9

Procedure up to present: Fit a single 2-dimensional 7 th order polynomial to each of the surfaces in slides 6,7 and 9 Calculate Xunc, Yunc from real-data button responses (‘scope or EPICS), correcting for “tails” Interpolate to the appropriate surface, giving Xreal, Yreal or Qf Advantage: gives a smooth mapping function Disadvantage: polynomial doesn’t fit well near to electrodes (and higher order produces extraneous peaks and troughs) New “Local-Fit” procedure: Calculate Xunc, Yunc from real-data, as above Identify local region of surface around Xunc, Yunc (e.g. nearest 25 modelled points) Perform a 2-D 2 nd order polynomial fit to this restricted dataset Either: use fit parameters to interpolate Xreal, Yreal values, or pre-calculate look-up tables (e.g. every 50 um) giving Xreal, Yreal, Qf for any combination of Xunc, Yunc Advantage: MUST produce a better fit to the modelled data than fitting to whole (-1,+1) surface Disadvantage: more susceptible to “steps” in modelled data – need denser modelled points IK March 1st 2012 Mapping procedures Slide 10

IK March 1st 2012 Mapped data for Xreal, Yreal and Qf – Cylindrical BPM Slide 11 XrealYreal Qf Compare mapped (fitted) surfaces using “local-fit” with original modelled data in slides 6,7 and 9: RMS deviation of fit from X and Y data ~< 100 um RMS deviation of fit from Qf data ~ 0.25 The RMS uncertainties in X and Y (and particularly Qf) will be considerably improved by modelling more points u sing CST – this is in progress

Cylindrical assemblies: Electrode responses L and R subject to same amplification “gain”; responses U and D potentially subject to a different gain. If gain for L,R is 1, and gain for U,D is “g”, can write: (So different channel gains have no effect on recovered positions) Rectangular assemblies: [after Alex. Kalinin] Simple differentiation w.r.t. g gives errors in Xunc and Yunc in the sub- 10 micron range for g < ~0.1 and typical values of A, B, C and D So for expected maximum channel gain differences, errors arising are << e.g. thermal noise, and this is borne out by mapping analyses IK March 1st 2012 A note about channel gains Slide 12

Difficult to gauge quantitatively, but contributions from: Modelling: - accuracy of CST representation of assemblies - accuracy of interpolation (using mesh of finite size) - mesh size < 400 um Mapping: - accuracy of global polynomial or local-fit approach to interpolate between modelled points typically < 100um for X and Y, and ~ 0.25 for Qf (see slide 11) Need to: - Look again at CST auto mesh generation more carefully - Re-run many more points under CST and repeat mappings IK March 1st 2012 Uncertainties arising from the mapping approach Slide 13

IK March 1st 2012 EPICS in use Slide 14 Only the essential “raw” data is stored in the EPICS database All processing and analysis of this raw data, including tail corrections, electrode responses, mappings, and other corrections (e.g. offsets) to be done on command by a LINUX based server box Peripheral software, “real-time” or off-line, can interrogate the LINUX box with a time stamp to obtain real X, Y and Qf values for any cell If such processing were done on the cards themselves: - slower response - not “future-proof” to changes in e.g. offsets or mapping procedure - any errors in processing would be irrecoverable