Re: [BLAST_ANAWARE] minutes analysis meeting

From: Chris Crawford (chris2@lns.mit.edu)
Date: Fri Apr 18 2003 - 12:52:02 EDT


hi tancredi,
  the problem we face now is not just the need to swim each candidate to
weed out the ones with bad chi^2; we actually need a preliminary fit
(few iterations) on each of the candidates before the chi square is
reliable enough to use as a cut criterion. hopefully this will be
solved with better wire chamber callibrations, and some improvements to
our fast fit.

  however, i agree with you that we can refine the fast fit with a
taylor-expanded function of the wire chamber stubs, and even calculate
an initial chi^2 using the same technique, to avoid swims in the initial
cut. this should be an intermediate stage between fast fit, and the
newton fitter. we can even use our existing code to fit for these
functions.

for example:
  x1,y1, x2,y2, x3,y3 -> p,th,phi,z (circle fit)
  x1,y1, x2,y2, x3,y3 -> dp,dth,dphi,dz,chi2
    (5 taylor expansons in 6 dimensions of residual error)
  then cut on chi2 from above polynomial function, and
    feed the selected (p+dp, th+dth, phi+dphi, z+dz)'s
    into the newton fitter

  using the taylor expansion to calculate the residual from the circle
fit instead of directly going to (p,th,phi,z) is a good idea because the
circle fit will deal with the nonlinear part of the function, leaving
something easier to fit.
  i think it is a good idea to expand functions of (x_i) instead of
(p,th,phi,z) so that you can apply the functions directly without
inverting them. also stubs are the ideal values to use, and they
represent a minimal set of independent data from the wire chamber. the
two extra degrees of freedom also make a chi2 function possible. this
would be the only cut we would have to make on the link level.
  this would be a relatively simple addition to the reconstruction
software, with the potential to dramatically speed it up.
--chris

Tancredi Botto wrote:
>
> > > In final v2 candidate tracks will be fit only in the Wch (no
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > prototype implemented and
> > check into CVS. Need debug, test and optimization. The (no swimming)
> > comment is not true. The swim is basicaly our function to be minimized. No
> > fit can be done without swim. We can only reduce the number of swim,
> > but never NO SWIM. :)
>
> You are absolutely right, put like this it makes little sense. What I
> meant to say (correct me if I am wrong again) is that you do not need to
> swim all candidate tracks to eliminate those that are built from inconsistent
> (combinatorial?) segments.



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