Comments on MRS tracking. A lot of work has gone into getting PID to work and this is greatly applauded. This always means some changes and addition of code to existing classes. As long as such changes are minor I think we can all agree this should just be done. On the other hand, in particular for persistent data object more is required. It should be brought up as a proposal before being implemented and certainly before being committed. Also it should be discussed where calculation of physics quantities should be done. Consider as an example the recent modification of BrMRSTrack. Let me try to make a brief analysis of the issue before coming to the problems as code has been implemented, I think in part without regard to the issue mentioned above. This is also related to an overall philosophy. The BRAT concept is to calculate properties of data objects within modules. The data objects are meant to be persistent. The framework of geometries, and parameters has been build around this. It is also possible to build an analysis framework around the concept of letting the (final) data objects (i.e. tracks) do all the work i.e. know everything about geometry etc, but so far this is not how things are set up. The overall track information is generated in multiple steps all in the BrMRSTrackingModule. 1.. Local tracking in TPM1, and TPM2 (From event node) 2.. Matching though D5 (presently only by effective edge) 3.. Project track to nominal beam-plane and get a vertex. 4.. Calculate track length Since these tracks are to be used for PID with TOF the path length is needed. It consists of multiple parts namely 1.. front tracking -> D5 -> back tracking station. 2.. From TPM2 to the TOF wall. 3.. From TPM1 to assigned beam vertex. The tracks at present are defined by (shortly) a.. front track b.. matched track (front and back also known here) c.. back track The piece of the path length that is due to magnetic field is clearly a property of the matched track not the complete track (unless a global total fit is done at the very end). The projection to the beam-plane ought to have some input from other vertex information i.e. a global vertex, or partial from global detectors. The track projection to the TOFW should be correlated with some hit selection on that wall; A path length without a hit-correlation does not seem meaningful. The track might have decayed. It is of course possible that it can be assigned equally probable to two (or more) hits. Thus I think that this piece of the track calculation belongs to the TOFW pattern matching. >From such analysis I would have concluded that a BrMRStrack should be organized something like a.. pathlength (from Helix calculation or otherwise in the matched track b.. pathlength to vertex ( from ProjectToVertex()); c.. pathlength to TOFW d.. reference (pointer) to vertex - info e.. reference (pointer) to TOFHit object (Does not exsist at present) This is one view of how to get to data object definitions; there are clearly other ways that might well be better, but they should be argued for. Now for some specific comments: The BRMRSTrack now has as data members (even persistent) pointers to all volumes in the MRS spectrometer. This is done so a simple call mrs_track->PathLength() does all the work. For this to work obviously the track has to know about all volumes and the magnet in the MRS to do this calculation. This is done without regard to the work already done in the track matching. This piece of code have already projected stuff back/forth to the magnetic field. Why do this again, and possible introduced errors. Likewise the Helix code is both part of MRS and FFS tracks, will it also be part of the FStrack?. Clearly this is an effect of not assigning calculation responsibilities (code wise) well. The MRStrack do the work of finding what TOFW panel is hit - this is not right. It should be a property of a TOFW object (e.g. extended BrDetectorVolume) where you simply ask: "If and where does a line (track) pass a volume". As mentioned early such a model of letting the data-object do the work can clearly be done- but should it be introduced without discussion? I think not. I think it is important that we do get good code that can be understood and maintained fairly easily. Particular with quite a few people working on this we should communicate and agree, certainly not to the last detail, but on overall concepts. Take this comment in the spirit - being constructive critical with the aim of moving forward in some form of coherence - and at the same time appreciative that new functionality is added all the time. So let us have a discussion how this should be done before implementation. Looking forward to comments. Best regards Flemming ------------------------------ Flemming Videbaek Physics Department Brookhaven National Laboratory tlf: 631-344-4106 fax: 631-344-1334 videbaek@bnl.gov
This archive was generated by hypermail 2b29 : Tue Sep 26 2000 - 20:29:13 EDT