Re: [BLAST_ANAWARE] k factor in WC calibration

From: Douglas Hasell (hasell@MIT.EDU)
Date: Thu Feb 05 2004 - 18:53:56 EST


Just a few comments.

> On Thu, 5 Feb 2004, Aaron Joseph Maschinot wrote:
>
>>
>> high theta hits that hit the (lorentz-angle-shifted) isochrone region
>> but
>> reconstruct outside the cell aren't too common (at least i don't see
>> too
>> many in the monte carlo). maybe we could play some game with trying
>> to
>> calculate the 1/2-way falloff point of the reconstructed position
>> histgram and (somewhat arbitrarily) get a first guess at k?
>>
>
> I second very much this point. And I want to make 3 points : (!!!)

It may well be that the percentage of tracks that are digitised inside
a cell but reconstruct outside of the cell is small. The problem
should be worst in the forward direction where the track is at a large
angle relative to the normal. Note reconstructing outside the cell only
occurs for in-bending field. Out-bending field reconstructs inside the
cell. To get an idea of the magnitude of the problem remember that the
Lorentz angle is around 5 degrees say 100 mr so across the 4 cm drift
this causes a 4 mm shift. The drift "jet" itself is maybe 10 mm wide so
for the forward cells the digitised position could be 4 + 10/2 = 9 mm
off the sense wire plane. The track angle relative to the norm is
around 50 deg so the reconstructed position is 9 tan(50) =11 mm further
out. So this naive calculation would imply that for the very forward
cells that about 25% ( 2 x 11 / 78 ) of tracks should appear as outside
the cell. At backward angles this affect disappears and even reverses
beyond 70 degrees or so.

>
>
> 1) Of course we can argue about cell boundaries and probably
> intercellular
> events are a better definition (at least logically). But we should not
> miss on the issue of "size". Maybe we wouldn't quibble as much over 1
> mm,
> but when X_drift spans a range of 7 cm instead of 7.8 then it is clear
> that we are not using the wch data correctly. Maybe this was only the
> case
>
>
> 2) The run plan is to reverse the field. It is possible that - for the
> same calibration - the momemntum resolution is bad at reverse field and
> closer to design values for inbending. But really the comparison is to
> be
> made for calibration files of *equivalent* quality ! In other words,
> as I
> continue to argue, the most important priority is to image back the
> wires
> and the chamber, and force the calibration to be consistent with what
> we
> expect. So let's determine K-factor for inbending and outbending.
> When we
> either find the same factors, or have 2 calibrations files showing
> similar
> quality for X_drift in the 2 BLAST configurations, then we can compare
> reconstruction results and possibly conclude about an intrinsic limit
> to
> the reconstruction accuracy. In this sense btw, we don't need any new
> data
> to study the issue, but I won't argue against that.
>
>
> 3) Sure there are caveats. But I hope the caveats won't be strong
> enough
> to explain a 10 % shorter cell lenght ! In a worst case scenario,
> events
> from the edge of the cell are simply lost due to some unexpected
> intrinsic
> inefficiency, our max tdc value corresponds to only 6.5 cm from the
> wire
> and our k-factor are a mockery.'
>

The maximum drift distance is 3.9 +/- 0.05 cm.

> Well, I think there is some way to control the K-factors other then
> "arbitrarily" drawing a cell boundary at 7.8 cm. Infact if the drift
> velocity is really (0.95*v_drift) this will show at all drift distances
> not just the largest. I suggest the following method: call x1,x2,x3 the
> measured drift distance for wires 1,2,3. Use any pair of position
> xn,xm to
> determine the 3 or missing position and adjust the scale factor for
> the 3
> wire.
>

This is already done in the calibration. Within a cell there are 3
wires each with a t0 and a dx correction. So 6 free parameters. The
fact that you have to simmultaneously solve things for tracks left and
right of the sense wire means that there are really just three free
parameters per side. One parameter is used by fixing the absolute
position of the track (ie parallel shifts away or towards the wires).
Another parameter is used to fixe the angle of the track. The third
parameter is fixed as you describe above to put all three points on the
same straight line. If we know the position vs time relationship
correctly these corrections work for all tracks regardless of angle or
distance from the sense wires. The k factor we are discussing is
another parameter to account for our ignorance of the drift speed in
the gas and is used to match tracks crossing cell boundaries.

> Once it is repeated for all pairs, or fitted simultaneously, this
> method
> shoud give the "best" or most consistent k-factors relative to geometry
> and straight tracks (assume a track is "straight" in a cell). With
> OOPS
> (any other spectrometer really) we used this method to determine the
> precise alignement of 3 wire chambers in a detector package. It is our
> "resolution tune up"
>
> In this way you force the calibration to be consistent with the data.
> It is really ok. Nobody should force a physical interpretation of the
> calibration parameters, but that's ok too. It would be interesting to
> plot
>
> (x1+x3)/2 vs x2
>
> where x1+x3, after the staggering has been taken into account, gives
> the position of the track at plane 2. Data in this plot should cluster
> around the line with slope =1, intercept =0. Else we need to fix x2.
> And
> maybe be ready to adjust the slope *and* the offset (a cumulative
> correction to x0,t0) which requires looking at both side of the track.
>
> When x2 is "fixed", you move on iteratively until you find a stable
> point.
>
>
>
>
                                                                         
             Cheers,
                                                                         
                                      Douglas

26-415 M.I.T.
Tel: +1 (617) 258-7199
77 Massachusetts Avenue Fax: +1 (617)
258-5440
Cambridge, MA 02139, USA E-mail:
hasell@mit.edu
On Feb 5, 2004, at 2:13 PM, Tancredi Botto wrote:



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST