Hi, allow me to sell our idea of DST here. it is almost done in v3 with
some minor cliches left to be straightened out. it will book the hits used
by a track. not just all the hits but hits by track. and functions are
implemented to reconstruct the tracks and their hits from a dst event. I
believe, what Aaron whats is not just the hits but the hits within a
track, in order to do efficiency study. It would be a breeze from the
future dst. unfortunately, Aaron, you have to wait. :(
Chi
On Sat, 21 Jun 2003, Chris Crawford wrote:
> hi,
> the problem with a single pre-canned ntuple is that most applications
> need to process wire chamber data event by event to extract meaningfull
> results. for example look at adjacent hits, or some correlation between
> the hits of a single stub. none of this can be done with the standard
> ntuple Draw() command. for this reason, i recommend using a compiled
> program like 'wc_hit.cc' which gives you more flexibility in your analysis.
> --chris
>
> Tancredi Botto wrote:
>
> >Aron,
> >just to let you know that there is a wch ntuple: look into wch_ntuple.C of
> >course. This ntuple will store each physics event Nhits times, where
> >Nhits is the number of wch hits. So if in the ntuple you cut on physics ev
> >number you will have all the wch hits related to it.
> >
> >This was done to address the issue of ntuple with varying number of
> >fields. Of course you could restrict to events with, say, 40+40 hits but
> >then you would need a tree structure (see scaler_ntuple.C) since the
> >ntuple fileds will be close to 100.
> >
> >Now you may just want to take wch_ntuple, copy it over, add the tracks and
> >restrict output(filling) only to events with meaningful tracks. This
> >essentially corresponds to recrunching. If it is a lot of files, it could
> >be a cpu problem right now
> >
> >
> >
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST