Re: [BLAST_ANAWARE] minutes analysis meeting

From: zhangchi (zhangchi@general.lns.mit.edu)
Date: Fri Apr 18 2003 - 12:29:15 EDT


Unfortunately still have to. It is done this way:

Track finding has it own way to define a track. it may throw away some
obviouly wrong tracks and pass all those it thinks good on to the next
stage.

Most of the times, it is fine but we do have events that Newton fitter
recieves a lot of candidates, sometimes close to 100.

Newton fit knows very few things about track quality, one is chi square,
one is z0 vertex. The fit will be terminated if z0 drifts away from
reasonable values to out of range and the track will be abandoned.

The only other way to decide if a track is still a candidate is to watch
its chi squared which canonly be computed from a swim and compare the
trajactory to the hits.

Here is a bit more detail on the selection:

1st: take all the fast tracks passed along by Wc1TrackContainer, say
in a very bad case 50 of them. swim ALL of them once, eliminate ones with
excessive chi squares.

2nd: do a two iteration Newton fit with pretty large steps in swimming on
the ones left, could by 30 of them. compare the chi squares and eliminate
some more.

3rd: another two iteration on the ones left, could be 20 of them. compare
and eliminate again.

4th: another fit on the say 10 left. compare and eliminate again.

5th: a full fledged Newton fit on each track left, might be 5 left at hand
now. Once a fit achieve a very satisefactory chi square(set to 0.0001cm^2
compare to 0.00004cm^2 of chamber hit position resolution calculated
months ago), all other candidates from same set of hits are discarded to
further reduce the number of fit required.

The results of every stage is passed passed along and used by the next
stage to avoid further waste of CPU time. But for the moment, I do not see
a good way to determine track quality without swimming.

The tracks are always sorted by chi squared so the ones with smaller chi
square after the previos stage, i.e. the ones look more promising are
processed first. There are mechinism in each stage such that once one
track with VERY good chi square is found, all other tracks from the same
set of hits are discarded.

There are some cuts to determine what is deem a good, very good
nad extremely good track. Presumably we need to histogram some veriables
to set these cuts. But the wire chamber calibrations and track fitting
algorithms has been improving constantly the last few weeks so the
dynamics on chi square values is rather unstable. So I only eyeballed the
first 100 events in run 3070 and set them to some "reasonable" values.
Determine those cuts precisely at this stage, as I concern, is a waste of
man power and CPU time.

For further details:
check out a new copy of TBLRecon.cc where there is a "printflag" set on
line 41. set its value to 1. There all the prefit process will be dumped
to screen. Just watch run 3070 the very 1st event with wire chamber hits,
it will give a feeling of how the things are handled.

For further further details, read TBLRecon.cc, under the header:
//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@//
// Prefit and Select tracks before fullfledged Newton fit //
//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@//

line 951. ^;^
 
Cheers.

Chi

On Fri, 18 Apr 2003, 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