Hi Djam et al, On Mon, 22 Oct 2001 03:22:50 +0200 (CEST) Djamel Ouerdane <ouerdane@nbi.dk> wrote concerning "Calibration and tracking": > Hi all, > > I would like to announce here that the calibration package for the TOF > detectors in its latest and greatest shape is about to be released, I'm > testing it with TOFW and got a very very preliminary PID (but the cal. > I've made is very rough and I need to fix a couple of things before). > It will come with some documentation and I would like to start a serie of > BTN, Brahms Technical Notes, describing in details how one should use the > software on which data, trigger and vertex conditions, etc. how one can > check the cal. and how one can insert it to the DB and read it back. Someone probably need to grant some permissions on rcf:/export/brahms/WWW for you to be able to write there. Also, I'd like to take this oppertunity encourage people to set group read-and-write permissions to all files in that area, so that we all may fix bugs, spelling errors, etc. on our web-pages. > Ok, now comes a part that some of you might dislike but I found it > necessary to do it this way: in order to make things useable for all TOF > detectors, I had to rewrite the global track classes. What follows is a > description of the stuff in my own brat: > > new classes: > > BrGlbTrack : derive from TObject > BrFfsTrack : derives from BrGlbTrack > BrMrsTrack : idem > BrBfsTrack : idem > > Now, the global track class has all the common stuff of the derived > classes: > > ----------------------------------------------------------------------------- > BrGlbTrack content > > members: > UShort_t fPointedSlat; // pointed slat on closest tof plane > Float_t fTheta; // polar angle in deg. > Float_t fPhi; // azimuthal angle in deg. > Float_t fPathLength; // path length in cm > Float_t fPartialPath; // D1 to H1 for ffs, TPM1 to TOFW for mrs, > // H1 to H2 for bfs > BrMatchedTrack fMatchedTrack; // T(PM)1 - D(1,5) -T(PM)2 matched track > BrVector3D fProjOnTof; // Track projection on tof plane > BrVector3D fTrackVertex; // track vertex (intersection with beam > // line for Mrs, intersection with BB vtx > // plane for FFS, same for BFS if BFS not > // aligned with FFS, proj on H1 in opposite case) Well, this is really not a "Global" track is it? It's more like a spectrometer track isn't it? Hence the name is at least bad. Why don't you do a class like class BrDetectorHit { private: BrDetectorList fDetector; // Detector (may be magnet) ID Int_t fId; // Unique id for this detector public: BrDetectorHit(Int_t detId=0, UInt_t id=0) : fDetector(detId), fId(id) { } UInt_t GetId() const { return fId; } void SetId(UInt_t id) { fId = id; } virtual Double_t GetLengt() { return 0; } virtual BrVector3D* GetPosition() { return 0; } virtual BrVector3D* GetDirection() { return 0; } virtual BrLine3D* GetLine() { return 0; } virtual Double_t GetMomentum() { return -1; } ... }; class BrMatch : public TObject, public BrDetectorHit { private: BrDetectorList fFrom; // From volume BrDetectorList fTo; // To volume Int_t fFromId; // Id of hit/track in from volume table Int_t fToId; // If of hit/track in to volume table TObject* fFromPointer; //! Cache of from hit/track TObject* fToPointer; //! Cache of to hit/track Double_t fMomentum; // Matching segment momentum Double_t fLength; // Matching segment length public: ... }; which ties tracks/hits together with track hits. This kind of class is general enough to do vtx-D1-T1 matches T1-D2-T2 matches T2-TOF1 matches T3-D3-T4 matches T4-D4-T5 matches T2-void-T3 matches TPM1-D5-TPM2 matches The reason for using TObject* pointers rather than explicit BrTrack, BrVertex, BrTofHit, and so on, is that you do not want to limit yourself to various kinds of hits/tracks. Now, you want more than that, since you want the momentum, tracklength, and so on. So we do another class, which ties all of these kind of things together class BrParticleCandidate : public TObject { private: TObjArray* fSegments; // List of segments Double_t fLength; //! cached length Double_t fMomentum; //! cached momentum BrDetectorList fMask; //! cached hit mask public: Double_t GetLength() { if (fLength >= 0) return fLength; TIter next(fSegments); BrDetectorHit* hit; fLength = 0; while ((hit = (BrDetectorHit*)next())) fLength += hi->GetLength(); return fLength; } Double_t GetMomentum() { if (fLength >= 0) return fLength; TIter next(fSegments); BrDetectorHit* hit; fLength = 0; Int_t cnt = 0; while ((hit = (BrDetectorHit*)next())) { if (hit->GetMomentum() < 0) continue; fMomentum += hi->GetMomentum(); cnt++; } fMomentum /= cnt; return fMomentum; } BrDetectorList& GetMask() { if (fMask->GetMask() != 0) return fMask; TIter next(fSegments); BrDetectorHit* hit; fMask->SetMask(0); while ((hit = (BrDetectorHit*)next())) fMask->SetMask(fMask->GetMask() + hit->GetDetectorId()->GetMask()); return fMask; } ... }; class BrPid : public TObject, public BrDetectorHit { private: Int_t fPid; // public: BrPid(Int_t detectorId, UInt_t id, Int_t pdgCode); ... }; class BrTrack : public BrLine3D, public BrDetectorHit { private: Double_t fLenght; //! Chached length; public: Double_t GetLength() { if (fLength >= 0) return fLength; // Otherwise, calculate the length of this segment. ... } ... }; > This done, it is extremely easy to deal with Bfs or Mrs or Ffs tracks > without makeing seperate cases all the time. Other convenience: the > size of these classes is much smaller. But, you're still tied down to dealing with the "special" cases of FFS, BFS, and MRS tracks - as I said, not really global tracks at all. > Now, tell me if you want to switch to this because I don't want to > fool around too much with it, I don't have time and there's still > this old rumour that some people are working on a completely > different scheme. I think that a scheme as outlined above would do us much more good, and I do hope someone will pick up on that - 'cause I sure as h**l haven't got the time. > It took me a couple of hours to change names from FFS to Ffs, MRS to > Mrs, etc. It was not a waste of time at all and I still get the same > results without writing anymore some code specific to MRS or FFS > (could achieve this also with the new version of > BrDetectorParamsTof). > > If you all agree or don't have any opinion on this, I'll make it official > when the tests are Ok. If it helps you now, I think you should go ahead, but do realise that we need something more general (along the lines of the above) at some point, preferably sooner than later. > If you disagree with valid arguments, I'll switch back to the old thing. That's probably a step in the wrong direction, so I don't think you should roll-back. > Note that the old stuff will still be part of brat, of course. Why? Does anyone need it? If not, please remove it. If so, speak up now, or forever hold you tongue. > People reducing data at the global tracking level will only have to > do one thing: changing FFS for Ffs, MRS for Mrs. That should be > it. Note also that I'm testing the calib. sof. ^^^ ||| What does "Soldier of Fortune" has to with BRAHMS? 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 : Tue Oct 23 2001 - 09:01:43 EDT