[esa-t474] papaer - terminology
Alexey Lyapin
al at hep.ucl.ac.uk
Fri Sep 28 18:42:54 BST 2007
Hi Mark and all interested,
I just wanted to comment on the terminology and you will either agree or
disagree so that in the end we can discuss it in the meeting and fix it
for the paper.
So, suggestions:
- resolution - by definition is the smallest beam offset the BPM can
measure, so it's fine to call the RMS we measure with 3 BPMs multiplied
by some magic factor a resolution
- precision - by definition, it's how well we can repeat the same
measurement, in case of one freshly calibrated BPM I think that the
precision is equal to the resolution, in case of a system of BPMs we
have a precision of the orbit reconstruction etc. The way I think about
it is that the precision is something you can improve by averaging. In
any case, I think it's a good practice to use "resolution of the BPM"
and "precision of the position measurement"
- accuracy - again, by definition, it's how close our measurement is to
the true value, and this one is not trivial at all as we use the beam
based alignment referring to BPMs themselves. I think we can only say
that the accuracy of our position measurement degrades with the time.
I hope we can sort the terminology out next week and never mind it again. =)
Cheers,
Alex
Bino Maiheu wrote:
> Hi Mark,
>
> An other set of comments on chapter 4 from Alex and myself.
> We weren't able to finish comments on the last two chapters by today,
> but I'll go through it in detail tomorrow and send it before I leave.
>
> Cheers,
> bino
>
>
>
> ------------------------------------------------------------------------
>
> General style remark for the figures
>
> - I hate the word "tilt", suggest replace it everywhere by "slope"
> which is much more commonly used in beam dynamics !!!!!!!!!!!!!!
>
> - add ticks !! ->SetTicky(), ->SetTickx();
>
> - ->SetLineWidth(1), otherwise when it gets NIM-ified, it'll look
> rubbish
>
> - precision -> resolution
> accuracy : we cannot measure !
>
>
> Comments to BPM commissioning paper Draft 3
> -------------------------------------------
>
> Chapter 3 : Kill it entirely & recycle it throughout the rest of the
> paper !!!
> 3.1 -> moves to 4
> 3.2 -> dissolved in the text where systematic effects are
> analysed !!
>
> Chapter 4 : Commissioning the BPMs
>
> -> kill 364->370 entirely, and replace by a much condensed version of
> section 3.1 which just has the *relevant* equations in there !
>
> -> So beginning of chapter 4 with old 3.1 :
> - when showing equation 8, we should make it clear that this
> formula allows us to distinguish between the offset and the
> angular
> component of the output voltage, provided we have a phase
> reference.
>
> -> Chapter 4 sectioning : suggest to change to :
>
> 4.1 Cavity frequency
> 4.2 Calibration
> 4.2.1 Corrector calibration
> 4.2.2 Mover calibration
> 4.3 System optimisation
> 4.3.1 Sampling point
> 4.3.2 Digital Filter Bandwidth
> 4.3.3 Attenuation and Alignment
> 4.3.4 Linearity of the BPM response
>
>
> - line 372 : get rid of "(V(t) in Eq.10)"
>
> - line 373 "...when downmixing to baseband (see Section 3.2.2"
> suggest replace by : "... of the DDC signal."
>
> - line 375 : need citation for MINUIT
>
> - line 376 : "To avoid low amplitude effects." : not clear to reader
> what is understood by this.
>
> -> suggest replace by something like : "The fitting is most
> efficient for large amplitude signals, so
> this fit was..."
>
> - line 377 : (~ 1 mm) ... make the cuts clear here !
>
> - line 378 - 384 + table 5 and figure 10 : need rewriting/rethinking !
>
> The way it is presented now is that one takes a period of 20
> hours ( is this acutally 20 hours, because from figure 10 ( the
> x-axis you can't tell ) ?) and fit for all the frequencies, put
> them in one big histogram and fit for mean and stddev. If the
> frequencies over this period are indeed distributed as a normal
> distribution, then fine, but then we can't show the drifts
> during this same period as this would mean that we fit something
> with a gaussian which is not gaussian at all.
>
> Suggest: we can present the data in table 5 from the first
> point, in figure 10, were we say that we assume the long term
> drifts to be small enough for us to assume that the obtained
> frequencies are normally distributed, but not take the average
> from the whole period !!
> In figure 10 we can then show what these drifts look like, but
> we definitely need some sort of uncertainty on these values
> because the way these figures are presented now, they show clear
> systematic drifts!
>
> - line 385 - 392 : do we need this ?
>
> - line 395 : as we got rid of section 3.2, we can put here section
> 3.2.3 instead of the brackets
>
> - line 396 : Differences of ~ 0.5 MHz were achieved for all by BPM1y
> ( 39.90 MHz vs 36.70 --> see table Table 5 )
>
> - figure 10 : in general - check Y axis labels
> - time axis : proper labelling
> - error bars needed !!
>
> correlation plot with temperture ?
>
> - table 5 : get rid of the "as q1" etc... just quote the values or
> use double quotes
>
> - table 5 : use the same precision ( number of significant digits )
> for the quoted numbers and their errors !!!
>
> - line 407 : probably best to have a correlation plot with
> temperature here to support the statements or at least
> give some
> indication of the temperature variation over the period
> considered.
>
> - line 412 : The killed section 3.2.2. should go here then...
>
> - Table 6 : Is very informative, we need something more in the sense
> of "If my frequency changes by this amount, then the
> resolution
> and accuracy changes by that percentage...".
>
>
> caption : "for each BPM if the physical frequency
> changed by the amount given in Table 5" ?
>
> What do you mean exactly, did you simulate BPM responses
> with a slightly offset frequency ? -> Need explanation!
>
> But if simulated, then what is the difference between
> the different BPMs when simulated ? Or did you change
> the DDC frequency and not the physical frequency ?
> -> line 413 -> 424 prob. needs a bit of rethinking in the wake
> of this comment
>
>
> - line 417 : Section ??
>
> - line 425 - 429 : This frequency change is not shown anywhere,
> might be a bit confusing, or we have to put in a
> plot showing it !
>
>
> - line 431 : $(\omega)$ -> $\omega$
>
> - line 433 : get rid of ($\Phi_{IQ}$ in Eq. 22) and similar
> references !
>
> - line 433 : scaling factor -> calibration or position scale
>
> - line 437 : kill sentence "This movement not only..."
> suggest replace : "...was applied, this way the rotation of the
> position axis and the scale could be determined."
>
> - Figure 11 : -> see general figure comments at top
>
> -> bottom left plot : I suppose this is "uncalibrated
> position" and not "measured", so should be in
> arbitray units, not mm.
>
> -> in the I vs Q plot, and the I,Q vs event number,
> show that there was a slight drift between step 3
> and 4, in I/Q : not equidistant fit point...
>
> ---> maybe use better calibration to demonstrate
> to show principle
>
> -> rephrase caption
>
> - line 441 : kill first three sentences !
> suggest change :
>
> "By varying the magnetic field of correctors XCOR32 and YCOR33
> in steps of 0.005 kG.m around the nominal value, we
> scanned the position of the beam in all the BPMs. As
> the change of the integral field of the magnets is known along
> with the location of the BPMs in the beam line, a simple
> calculation yields the predicted offset in each BPM at each
> step."
>
>
> - line 446 : "For each of these events..."
>
> suggest change : "For each of the steps, the I and Q values
> of the events were computed and fitted to a Gaussian to
> determine..."
>
> - line 447 "gaussian" -> "Gaussian"
>
> - line 448 : beam jitter is not really in place here, get rid of it!
>
> - line 448-452 : "The values at these set points...." needs a bit
> rewriting + some extra explanation
>
> suggest : "As the orbit correctors are far enough from the
> BPM stations, the induced slope is negligeable
> compared to the position offset, so that points
> (I,Q) for each step have to form a straight
> line. The $\Phi_{IQ}$ is then given by the slope
> of that line in the IQ plane. Applying a
> coordinate rotation of $\Phi_{IQ}$ to the IQ
> plane ( see eq...) yields the uncalibrated
> position. The calibration scale is subsequently
> determined from a straight line fit .... bla bla
> bla...."
>
> - line 458 : "A significant drawback..." .. true, but one could use
> BPM 31/32 ... maybe comment on that !
>
> - line 464 : "In addition to these problem..." until the end of the
> paragraph
>
> suggest rewrite : "In addition, there was no instrumentation
> available to monitor the actual magnetic fields in the
> correctors." full stop.
>
> - line 470 : Section 2.6 -> "section 2.6", but will probl be
> different number ! check it
>
> - Figure 12: Too large,
> Caption "relationship between the beam and a
> triplet"... don't really think they are in love ;)
>
> -> in fact, kill the entire figure, not very informative
>
> - line 471 - 474 : suggest replace by :
>
> "The beam jitter could be removed using the readings from
> the two outer BPMs in the triplet for the events in which
> the central BPM has moved. This results in a significantly
> more accurate method of calibration. Furthermore the
> horizontal
> position of these 3 BPMs was monitored by an
> interferometer, improving the calibration in x."
>
> - line 475 : "the Zygo interferometer" replace everywhere by simply
> "the interferometer", Zygo is a brand and is
> irrelevant and jargon.
>
> - line 476 : remove last sentence, accuracy already mentioned before
>
> - Eq 28 : Get rid of the k, and replace by 4. In ESA we only have 1
> BPM on a mover, so no need to have an index "k". Also
> replace the indices of the sum to "\sum_{i=3,5}"
>
> - Eq 29, see remark above and also the vector with the correleation
> coefficients should be a small letter, not capital "K" to
> indicate that it is a *vector* of values, not a matrix.
>
> - line 503 : get rid of the brackets around the (I), (Q) and (x)
>
> - line 505 : refer to eq 29 instead of 31.
> - line 505 : "First, the..." replace by "First, the position and
> slope readings of the outer BPMs"
>
> - Figure 13 : - left bottom shows no label
> - ticks, line thickness all 1 !
> - "Run 1374 has been used" ( run 1374 )
> - top plots x axis need different division scale (
> SetNDivision(...) or something in ROOT )
>
> - line 517 : -1 to +1 mm doesn't correspond with the predicted
> position in the bottom right graph of figure 13
>
> - line 517 : "...(the actual values....)". get rid of this, already
> mentioned
>
> - line 519 : "..were determined from the central BPM step"
> suggest replace by "...was determined from the middle step"
>
> and get rid of "(at zero relative offset)".
>
> - line 523 : typo "detemining".. missing r
>
> - line 527 -> 530 : needs rephrasing + discussion on what was done
> here !!
>
> - 4.3.3 : System optimisation : need some intro on alignment and
> attenuation bla bla as well, so add :
>
> "Also the gain of the electonics had to adjusted to fit the
> required range of the beam offset to the range of the
> digitisers. A beam based alignment techique has been applied
> to match the dynamic range of all the BPMs."
>
>
> - Table 7 :
> - sample point in MHz ??
>
> - gaussian -> "Gaussian"
>
> - caption "... to centre the gaussian filter." Hmm, sounds
> funny to center a filter around a point in time domain.
>
> - what do we learn from this table ? Not much we think, need
> some kind of reference, or say how far down the waveform
> from the maximum we are, so correlate with decay time.
>
> - Ah, but wait!! In the text it's mentioned that the sampling
> point is 10% down from the maximum, so don't think this table
> makes
> much sense.
>
> - Also, when we pick the point to be at 10%, it is not really
> optimising...
>
> ---> need some discussion !!!
>
> - line 544 : "... and the phase was stable." : this needs some
> explanation as this is not trivial. Need to refer to
> figure 9.
>
> - line 552 : "nagligible" : typo
>
> - Table 8 : we have to explain why the optimum values for the filter
> bandwiths are different. So what we're seeing is the
> effect of the short decay times for BPM3-5, resulting in
> a much more broadband response in frequency
> domain. Therefore, the filter needs to be more broadband
> as well in order not to cut in the signal and loose
> sensitivity.
>
> -> or something phrased a bit more decently in that sense !
>
> - Table 9 : the errors in the table are meaningless, get rid of
> them.
>
> - line 563 : "... was measured." -> "... was measured with a
> precision of a few micron."
>
> - section 4.4 : Need to mention somewhere :
>
> "Most of the BPMs were aligned to better than $\pm$
> 150 $\mu$m.
>
> - line 572 : what is "good ?" need to quantify "linearity".
> -> need a good definition of linearity !!1
>
> "The range in mm in which the BPM amplitude does not
> deviate from a straight line by more than some %"
>
> -> ideally even 0.05 % ( 500 nm resolution on dynamic range
> of 1 mm )
> -> need to discuss !!!!!!
>
> -------------------------------------------
>
>
>
>
>
>
>
--
===================================
Dr. Alexey Lyapin
Department of Physics and Astronomy
University College London
Gower Street
London
WC1E 6BT
Tel: +44 (0)20 7679 3454
Fax: +44 (0)20 7679 7145
===================================
Making good choices we win,
making bad ones we learn
===================================
More information about the esa-t474
mailing list