Hello,
I have committed some minor changes to Brat (very "quick and dirty hacks" to
allow linear matching of tracks with no magnetic field on, and to construct
BrFSTracks from T1, T2 BrDetectorTracks.)
The modified modules are:
In brat/base/..:
- BrMagnetVolume.cxx - modified SwimBack() - if no magnetic field, just
continue in a straight line through magnet.
In brat/track/..:
- BrMRSTrackingModule.h - added method GetCombineModule()
- BrFSTrackingModule.h - added methods GetCombineT1T2(), GetCombineT3T4() and
GetCombineT4T5()
- BrFSTrackingModule.cxx
- modified Event() to create BrFSTracks from T1-T2 matched tracks
- modified TrackToVertex() - if T1 track present, start there and swim back
through D1 to vertex.
- BrModuleMatchTrack.cxx - modified CombineFrontBack() - if no magnetic field,
just set P to some large value (hardcoded 99999 for the moment.)
The "short" BrFSTracks are put in the same table as before, "FSTracks".
Note that the spectrometer tracking modules still uses the nominal vertex
point, x=y=z=0, to calculate "vertex miss" Tx,Ty for the tracks after swimback.
This can easily be changed.
Otherwise, I think Djamel's suggestion about a more general and flexible global
track class (message included below, originally posted to a smaller sublist) is
a very good idea. People have been thinking for a long time that the existing
track classes are too cumbersome with too much hardcoding, but nobody had time
to sit down and revise them, and a volunteer would probably be most welcome - .
Best regards,
Trine
__________________________________________________________________________________
----- Begin Included Message -----
>From ouerdane@nbi.dk Tue Jun 20 20:48 MET 2000
X-Authentication-Warning: alf.nbi.dk: ouerdane owned process doing -bs
Date: Tue, 20 Jun 2000 20:49:10 +0200 (MET DST)
From: Djamel Ouerdane <ouerdane@nbi.dk>
To: Trine Tveter <trine@lynx.uio.no>
cc: videbaek@bnl.gov, pchristi@nbi.dk, b.h.samset@fys.uio.no,
a.k.holme@fys.uio.no
Subject: Re: Upcoming hacks in spectrometer tracking modules
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by alf.nbi.dk id UAA12314
Hi Trine,
I quickly read your message and that's good to put some efforts in it.
The first thing I have in mind is: what's the name of your table?
Do you create a table e.g. "FFSTracks" ? or does it have the same name as
before ("FSTracks")? My feeling is that we should have a real object
BrFFSTrack and not only a BrFSTrack since it would be much easier to
manipulate such an object (like MRSTrack).
My original thought was:
Having a single class BrTrack that one could either initialize this way:
BrTrack* track = new BrTrack("MRSTrack");
BrTrack* track = new BrTrack("FFSTrack");
BrTrack* track = new BrTrack("FSTrack");
and so on with some methods that can be common to all:
BrTrack::GetMomentum();
BrTrack::GetMatchedTrack(UInt_t trk1, UInt_t trk2)
with trk1, trk2 some index that are initialized in the constructor this
way (or global variables in the class):
enum trk { t1, t2, t3, t4, t5, tpm1, tpm2 } (enum is internally a type
UInt_t)
or you could do this with some strings as well ("T1", "T2", ...).
Of course, it would mean to rewrite these classes (task a bit similar with
my pid class). It's not that difficult but it demands some attention to
organize the structure of such classes.
I was thinking about that because the simple fact that the global tracks
classes don't derive from a _global_track_base_class_ make them difficult
to manipulate in e.g the tof-track pid class, there's a lack of
flexibility that can be avoided.
Does anyone have some comments about that?
If every one agrees I can rewrite these classes later (when I am back in
Copenhagen) and we can use
Trina's work in the meantime.
Djam
:o) ********************************* )o:
|ME : Djamel Ouerdane |
|EMAIL : ouerdane@nbi.dk |
|OFFICE : Tb1 @ NBI |
|INST : Niels Bohr Institute |
| Blegdamsvej 17, |
| DK-2100 København Ø |
| Danmark |
|PHONE : +45 353 252 69 (office) |
|HOME : Julius Blomsgade 31, 2TH |
| 2200 Copenhagen N |
| Danmark |
:oD ********************************* \o:
----- End Included Message -----
This archive was generated by hypermail 2b29 : Wed Jun 21 2000 - 17:41:05 EDT