Re: [BLAST_ANAWARE] reconstruction efficiencies

From: Chris Crawford (chris2@lns.mit.edu)
Date: Sun Jul 20 2003 - 18:19:08 EDT


hi doug, tancredi, chi, tong, wang,

Douglas Hasell wrote:

> Hi Chris,
>
> Look fairly good but why aren't you using the more recent runs?

i was using ep-elastic for good kinematic cuts, but now that you mention
it, i just need e+p tracks for my analysis. i'll try the most recent
runs asap.

> Up until 2-3 weeks ago there were problems with 2-3 boxes and
> its possible some of the thresholds were also too high.
>
> If the wire chambers appear to be inefficient then we can raise
> the operating voltage and/or lower the thresholds. If it is still a
> problem we can change the resistor chains again to gain about a factor
> of two in signal but that would take a 2-3 day shutdown.

hopefully we can decide very soon whether to do this or not, to make
sure we are taking the best possible wire-chamber information. i was
also wondering if perhaps some of the hits close to the wire are being
lost, since their gaussian distribution extends below zero? i think it
might be a good idea to extend this cut (and the t2d function) to
slightly negative tdc's

Tancredi Botto wrote:

>Chris,
>I believe that blue means fast fit tracks, green means newton tracks
>(ie. not no fast fit, not no newton)
>
no. black is tof cuts but *no* stubs, blue is *no* fast fitter, green
is fast fit but *no* newton, and red is both fast fitter and newton tracks.

>It'd be very good if recon efficiencies are limited to events with less
>than a perfect hit distribution. I think it is a matter of learning how
>to deal with stubs only or even fake stubs and with crossing-cell tracks
>
>Somehow (this is limited statistics) I have the impression that things
>were not as bad for v2_15 back in march.
>
yes, i definiately need to be more systematic and use more statistics.
 but looking at these things one track at a time... things are
definately improved since v2_15 (last year).

>But it should be use to plug boxes in and out of MC, which may be
>a useful debug for FF/newton. Also, a better FF may help on these
>issues
>
i think the ff is pretty much in shape.

zhangchi wrote:

>things were not as bad in v2_15 at expense of resolution. if we include
>just everything that fits remotely to a curve somewhere, ofcourse we get
>very very good efficiency.
>
this is a good point. we really should be using the same cuts on chisq,
for reporting both efficiency *and* resolution, since there is a
trade-off between the two.

>however, remember the resolution we started with? resolution is improved
>by improve tracking algorithm, calibration and in the sametime, by being
>more selective on tracks to be considered. then those tracks fit to poor
>quality show up and were removed from the track list.
>
i agree. i feel quite strongly that a good calibration should fix our
resolution, since the resolution within a sigle stub is up to design
specs! note also that our efficiency problems occur at low theta, where
the stubs cross cell boundaries. also, fixing the code to use even more
real hits instead of fake stubs will improve resolution for 'problem
tracks'. the other thing that i forgot to mention would be an adaptive
newton fitter that make corrections for which side of the wire was hit.

>dynamically cutting on stubs/segments/tracks may be a solution, if it dose
>not
>
>
???

Frederick Tong-Uk Lee wrote:

> Chi,
>
> I like the dynamic cuts on stubs/segments/tracks.
> Here is my suggestion:
> Ch^2 Cut in stub is one number for all cells right now.
> Maybe, we should change this to 1000 numbers; one for each cell.

i was thinking more of using the best chisq, plus any within a certain
margin of it. (or a second pass that used stubs with worse chi sq if the
first pass failed, but this would be a lot more work!)

> We then try to minimize this ch^2 cuts based on each cell.
> I am sure we can go lower than ch^2, 180, which is currently set for
> all cells,
> for the most of those cells. Our goal should be closer to 1 to 10.
> When we are making fake stubs, we should give some identifier,
> such as 3-hit-stub =3, 2-hit-stub=2, 1-hit-stub=1, no-hit-stub=0.

done. plus, -1 = one-hit stub made from fake stub (chi, is this right?)

> Actually, I have done this for 3 and 2 hit stub but numbering systems
> slightly different. I actually use bit pattern to find out which wire
> got hit, such as 7 (111) for all three wires hit and 6 (110) for first
> and
> second wire got hit. You can use this bit pattern for 1 and 0 hit
> stubs, too.
> And then when we are fitting tracks, we use these information
> for selecting the best track.

also done. (except adding number of hits into figure-of-merit of the
fit. not quite sure how to do this the right way. do i just divide
chisq by some funtion of the number of hits in each stub? what would
that function be?)

> As the calibration gets better, I am confident
> that tracks based on three hit and two hit stub will almost "always"
> better than
> those based on one and two hit stubs.

i agree. even if it doens't have a better chisq, it will certainly be
closer to the *real* track. (unless we include spurious hits)

Wang Xu wrote:

>Dear Chris,
> It is very nice.
> From your graph and my experience, the efficiency of newton fit
>can still be improved. Because new fast fit find the tracks, but newton
>
yeah, i've seen cases where the newton fitter did not converge. it
might have some problem in phi, i'm still investigating this.

>fit may not. I believe efficiency of new fastfit(or fast fit)should be
>same or very close.
>
the only efficiency problem with the current ff seemed to be overload
from too many links. anyways, i think ff works pretty well and is a
finished story.

--chris



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