Another way around the problem could be to make 2 methods in BrDetectorHit, something like : Bool_t MatchHitCluster( BrTPCHitCluster* ) ( if ID == ID ..) and BrTPCHitCluster* FindMatchingHitCluster( BrClonesArray* ) (Loop over clonesarray, MatchHitCluster() ....) (and maybe also one for a datatable) It would be more time consuming but work almost as well as the other solution and could propably be made nicer using some more hardcore c++ or ROOT stuff. Cheers, Peter :-) --------------------------------- )-: |Peter H L Christiansen aka PAN @ NBI | |EMAIL : pchristi@nbi.dk | |OFFICE : Tb1 @ NBI | |PHONE : 353 25269 | |SNAIL : Hans Tavsensgade 35, 4th | |PHONE : 35 349336 | :-D --------------------------------- \-: On Mon, 13 Nov 2000, Flemming Videbaek wrote: > I will add comments later to the specifics of the de/dx (as well as other > issues). > Ones people modify datastaructures that may be written onto root files, you > MUST add a streamer method if > not already there and update the version-number in the ClassDef macro. > > In general pointers should NOT be persistent i.e. use the / / ! in the > comment for the def since otherwise > the automatic root streamer may or may not output the object. Ownership > considerations are quit important here. > (This is in part why one uses IDs rather than pointer but at expense of > time..) > > Flemming > > > > > Hi > > > > In BrTPCHitCluster I have added the pointer to the BrTPCCluster, so there > > one does not have to match. > > It would of course be nice if the web page was updated more often so that > > this could be seen on the web. > > > > I like the idea with a pointer in BrDetectorHit and using the file://! > option > > so that it is not streamed out. > > > > Cheers, > > Peter > > > > :-) --------------------------------- )-: > > |Peter H L Christiansen aka PAN @ NBI | > > |EMAIL : pchristi@nbi.dk | > > |OFFICE : Tb1 @ NBI | > > |PHONE : 353 25269 | > > |SNAIL : Hans Tavsensgade 35, 4th | > > |PHONE : 35 349336 | > > :-D --------------------------------- \-: > > > > On Mon, 13 Nov 2000, Jens Ivar Jordre wrote: > > > > > On Mon, 13 Nov 2000, Claus O. E. Jorgensen wrote: > > > > > > > > > > > Hello everybody > > > > > > > > I would like to start a discussion on how to get > > > > dEdx information for the local tracks. Right now > > > > the only way to do it is to get the BrDetectorHits > > > > and look through all the BrTPCHitClusters to see > > > > which hit matches which cluster and then get the > > > > energy from the cluster. As I see it we have 3 > > > > options: > > > > > > > > 1) Keep it the way it is. > > > > > > > > 2) Let the BrDetectorHit have an Float_t dEdx > > > > member and corresponding get and set methods. > > > > > > > > 3) Let the BrDetectorHit have a void pointer to > > > > the BrTPCHitCluster (or the BrDCCluster) and > > > > corresponding get and set methods > > > > (void* GetMotherCluster() and SetMotherCluster(*void). > > > > > > > > As I see it the latter is the best solution. It > > > > will make it easy to get the energy, and we'll > > > > avoid having a not-defined dEdx for detector hits in > > > > the DCs (these detectors don't measure the energy, > > > > as far as I'm informed). > > > > > > > > Any comments? > > > > > > Here comes the first one. > > > > > > I agree with you. The 3rd approach resembles what is implemented for > > > tracks, where BrDetectorTrack has a pointer to its mother BrLocalTrack. > > > > > > Also present in the current version of BRAT is ID inheritage, i.e. new > > > instances of BrDetectorHit inherit the ID from their mother > > > BrTPCHitCluster, which again inherits ID from its mother BrTPCCluster. > > > This may be what you refer to as matching hits and clusters. But it is > > > arather time consuming process to match ID compared to getting the > mother > > > data structure from a pointer. I therefore support your view. > > > > > > JI > > > > > > --- > > > Jens Ivar Jřrdre, Dep. of Phys., Allégt. 55, N-5007 BERGEN, NORWAY > > > room 521, e-mail: JensIvar.Jordre@fi.uib.no, phone: (+47) 55 58 27 92 > > > > > > > > > > > > >
This archive was generated by hypermail 2b29 : Mon Nov 13 2000 - 11:22:13 EST