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.
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)
Methods:
// setters
void SetTrackId(Int_t id) { SetUniqueID(id); }
void SetTheta(Float_t theta) { fTheta = theta;}
void SetPhi(Float_t phi) { fPhi = phi;}
void SetMatchedTrack(BrMatchedTrack* t) { fMatchedTrack = *t;}
void SetPointedSlat(Int_t slat) { fPointedSlat = slat; }
void SetProjOnTof(BrVector3D v) { fProjOnTof = v; }
void SetPathLength(Float_t l) { fPathLength = l;}
void SetTrackVertex(BrVector3D vtx) { fTrackVertex = vtx; }
void SetPartialPath(Float_t l) { fPartialPath = l; }
// getters
Int_t GetTrackId() const { return GetUniqueID(); }
Int_t GetPointedSlat() const { return fPointedSlat; }
Int_t GetStatus() const { return fMatchedTrack.GetStatus(); }
Float_t GetTheta() const { return fTheta; }
Float_t GetPhi() const { return fPhi; }
Float_t GetMomentum() const { return fMatchedTrack.GetMomentum();}
Float_t GetPathLength() const { return fPathLength;}
Float_t GetPartialPath() const { return fPartialPath;}
Double_t GetMatchChisq() const { return fMatchedTrack.GetMatchChisq(); }
BrVector3D GetProjOnTof() const { return fProjOnTof; }
BrVector3D GetTrackVertex() const { return fTrackVertex; }
BrVector3D GetEntrance() const { return fMatchedTrack.GetEntrance(); } // local to mag
BrVector3D GetExit() const { return fMatchedTrack.GetExit();} // local to mag
BrMatchedTrack* GetMatchedTrack() const { return (BrMatchedTrack*) &fMatchedTrack;}
BrDetectorTrack* GetFrontTrack() const { return fMatchedTrack.GetFrontTrack(); }
BrDetectorTrack* GetBackTrack() const { return fMatchedTrack.GetBackTrack(); }
Float_t RelativeOverlap(const BrGlbTrack*, Float_t z1, Float_t z2,
Float_t r1, Float_t r2);
-------------------------------------------------------------------------------
The derived classes have few other extra things
Nothing more for the MRS track
Some D1 information for the FFS track (entrance and exit lines, swim back
status)
Some more things for BFS since with have 2 matched tracks
-----------------------------------------------------------------------------
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.
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.
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 you disagree with valid arguments, I'll switch back to the old thing.
Note that the old stuff will still be part of brat, of course.
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. with these new track classes
and it works fine :)
Now, I'm waiting for comments, critics, screams...
Ciao
Djam
--
Djamel Ouerdane ------------------------------------------o
| Niels Bohr Intstitute | Home: |
| Blegdamsvej 17, DK-2100 Ø | Jagtvej 141 2D, |
| Fax: +45 35 32 50 16 | DK-2200 Copenhagen N |
| Tel: +45 35 32 52 69 | +45 35 86 19 74 |
| http://www.nbi.dk/~ouerdane |
| ouerdane@nbi.dk |
o---------------------------------------------------------o
This archive was generated by hypermail 2b30 : Sun Oct 21 2001 - 21:23:29 EDT