Re: [BLAST_ANAWARE] less than 3 segment track finding

From: Tancredi Botto (tancredi@mitlns.mit.edu)
Date: Mon Mar 17 2003 - 23:34:47 EST


Hi chi,
while you may have a point about DetRecon and Wch i think your
fake stub should only use the tof info

a) that way is never biased, since tof position is indeed
   measured and is part of the event

b) can you at least try it so that we can compare speed ?

c) true you may get into ambiiguos cases when you have two close tracks
   going to two close tofs, but the ambiguity could be resolved by the
   newton fit eventually

z) we should not overlap code. Care to join us wendsnday at 10 ? (by phone?)

-- t
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Mon, 17 Mar 2003, zhangchi wrote:

>
> Hi all,
>
> As promised, I checked in codes for 1-segment and 2-segment track finding
> into BlastLib2.
>
> There is one function TwoSeg() added to TBLWc1SegmentContainer, one
> function OneSeg() added to TBLRecon. TBLWc1Segment and TBLWc1Stub are
> changed a little bit for the new algorithms, mostly for the test of stubs
> not paired up with any other stubs, and to count number segments in each
> chamber.
>
> Both functions construct fake stubs out of phi information from existing
> segments and combined with TOF position in the case of OneSeg(). then
> existing codes to construct Segments from stubs are borrowed almost
> without change.
>
> TwoSeg() overlaps with Tongs codes, I checked it in anyway since I have
> made it work anyway.
>
> OneSeg() is in TBLRecon since it uses TOF data and I do not want to mix
> DetRecon into WireChamber part of codes.
>
> it is called after
> *fSegs << *fStubs;
> and before
> *fLinks << *fSegs;
>
> With these functions, track finding efficiency in number is definitely
> improved, a few examples are run 3070 event #1, #4, #7, #13, #18(this
> event is very slow) etc.
>
> they introduce very messy cases to Newton Fitter and have an impact on
> run time. I need to add segment quality check and tune the codes a little.
>
> Chi
>



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