Re: [BLAST_ANAWARE] reconstruction efficiencies

From: Douglas Hasell (hasell@MIT.EDU)
Date: Fri Jul 18 2003 - 09:30:05 EDT


Hi Chris,

        Look fairly good but why aren't you using the more recent runs?

        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.

--On Friday, July 18, 2003 3:43 AM -0400 Chris Crawford
<chris2@lns.mit.edu> wrote:

> hi,
> i went through quite a few events in nsed in an attempt to trace down
> inefficiencies in the wire chamber reconstruction. the enclosed
> histograms break down the misreconstructed events in one paddle
> combination (0-14) (i also did 1-14, 1-13). the sample data set was
> taken from runs 705-708 (first 25k events in each), and strict cuts were
> placed on timing and coplanarity. black: events w/o 3 segments; mostly
> no hits in entire chamber, partially an issue of acceptance; found 1
> tree event blue: no fast fit track; mostly overloads (too many segment
> combinations, fixable by loosening cut) green: no newton fit track:
> mostly from 3-4 stub events, with ~8/18 hits red: good events
>
> conclusion: the inefficiencies are mostly due to wire chamber
> efficiency and calibration, although some improvements are possible in
> the sofware to salvage these events. the forward events are less
> efficient because of missing hits, miss-calibrations between adjacent
> cells (these stubs are almost never 3 hits in one cell), and a more
> complicated acceptance region for curved tracks (as opposed to a true
> inefficiency). some things which should be improved in software: a)
> make more of an effort to use real hits instead of fake stubs (no hit
> data). this is important for the newton fitter. b) smarter (dynamic)
> cuts so i) that we don't loose real stubs/segs/tracks, and ii) we don't
> get bloated/overloaded with too many tracks. hopefully better
> calibrations will abate this problem, anyways. in my limited viewing of
> the data, i did not find any obvious bugs in the reconstruction software,
> and almost of the missed events were due to the above explanations.
>
> finally, if possible, i would like to take a short unpol H run at .5
> sccm (~1/2 hr) sometime, to have some more recent data for WC
> callibrations, and testing reconstruction efficiencies. since the runs
> 700-800, some of the missing cells have been restored. i would like to
> see how this improves our current reconstruction. --chris

                                                  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



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