Hi Peter, Jens Ivar, Flemming, JH, and others, [I put this mail to brahms-dev-l, since that's the proper forum for these kind of discussions - off-list activity is to be frowned upon I believe] On Wed, 31 Oct 2001 14:00:22 +0100 (CET) "Peter H. L. Christiansen" <pchristi@nbi.dk> wrote concerning "Residuals": > Hi Flemming and Jens Ivar > > As you know we had a meeting in Copenhagen between Norway and > Denmark. One of the discussions were about reducing data. As you > know Ian is trying to get calibration and reductions shift > started. One of the elements of the reduction shift was to reduce > local tracks in all tracking detectors TPCs and DCs. Dieter had the > idea that track residuals should be stored with a local tpc > track. This will be useful when doing HBT to seperate close tracks > (avoid ghost duplicates), but in general I came to like the idea and > think it is something we would all appreciate. It among other things > allows refitting of the whole global track in a conceptual easier > way then using the covariance matrix and we can later make a > detailed study of residuals and estimate the chisquare/confidence > level better. > > I have written to you to ask your opinion. > > The idea would be to implement it something like this : > > Have a TObjArray in BrTpcTrackCandidate or have a fixed array(12 > bins). This makes it easy to store the value in trees since the > class will still have a fixed size and nHits can be used to get the > number of actual residuals but also waste space. > > Have a small residual class with dx, dy, adc_max, row (This could be > compressed or simply 2 Floats and 2 shorts). When the tracking is > done have a make residuals method that fills the residual array. > > He also stressed that energy calculations of the tracks should be > done with a truncated mean to avoid landay tails, so I was think > about removing that part of the BrTpcTrack if we include residual > information with the energy). > > What do you think about these changes ? > > Cheers > Peter On Wed, 31 Oct 2001 10:10:49 -0500 Flemming Videbaek <videbaek@sgs1.hirg.bnl.gov> wrote concerning "Re: Residuals": > Peter, > > It seems like a sensible idea to me - since the class is always > together with the local tpc track Could the rersiduals be stored as > a small clonesarray - will that not be the optimal amount of storage? > > Why store max adc and not sum(adc) - the latter represents the total > charge in the cluster which max adc does not necs do (bin size > effects). It is ok to think about the de/dx but there is no region > of phase space where we cannot do PID with TOFW - to me this is only > a tool to confirm the pid not to actually have it as the sole info. > > Flemming On Wed, 31 Oct 2001 10:43:38 -0500 Jens Ivar Jordre <jensivar.jordre@fi.uib.no> wrote concerning "Re: Residuals": > My general comment is that this is a good idea. > > Flemming Videbaek wrote: > > Peter, > > > > Could the rersiduals be stored as a small clonesarray - will that > > not be the optimal amount of storage ? > > I second that. In addition to storing the residuals in a > TClonesArray, in my opinion the size of the array should equal the > number of hits in the track. That means that in order to relate the > instances of residual to their hits, one would use the row > number. But the row number does not have to be bigger than a 8 bit > integer. Then we don't waste much space. > > I'd say somthing like > > class BrTpcResidual : public TObject { > private: > UChar_t fRow; // Row number > Short_t fAdcSum; // Intergrated ADC > Float_t fDeltaX; // X residual > Float_t fDeltaY; // Y residual > ... > } > > JI <grin>Except me to have a few words on this</grin>. 1) If you want to store the residuals, it should be as a TClonesArray. Possibly you could also have some way of not storing the data, if the user does not care - default behaviour is up to you guys. 2) Do not use UChar_t to store numbers - overloading the semantics of types is a bad thing. Instead, use something like Byte_t (note that it gives you the range 0-255), but why not just use a Short_t, since you may want to encode the row and pad number into that member, like say row = fPadRow >> 8; pad = (fPadRow & 0xff); Then you don't need to care about the order the residuals was added. 3) Maybe you should talk to the DC people and perhaps figure out some common scheme if possible (remember - abstraction, abstraction, abstraction - this is C++ not Fortran!) Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Wed Oct 31 2001 - 13:41:42 EST