I think this is because the matching is (and this is a VERY BAD idea, IMHO) done based on H1 hits. Or at least it was. I think that Flemming is right, we should have a module which works just like BrModuleMatchTrack, but with no magnet. On the other hand: Is it possible to define a "fake" magnet which is just a plane in space so that we could use the same module for matching? I guess it is a matter of copying the matching module, or making a weird magnet volume, or there is something I haven't though of... -Ian On 15/6-2004, at 03:17, flemming videbaek wrote: > Hi > Just a short comment. > I am clueless why T2-T3 matching depends on H1, H2 calibrations. This > should > only be a function of > tracking detectors - so I will go along with a solution for matching > that > looks like BrModuleMatchTrack, but will > strongly disagree to let this module dela with T2,T3 matching (the is > no > filed involved). I have sai this before > and will thus repeat. One coul make a matching approximately like this. > We should also recall that due to the independence of FFS an BFS there > may > be small systematic geometry > difference, most likely in the x-offsets an not in angles that can > effect > how we do t2-t3 matching and t2-t4 matching. > > Note this is not a complete note, but summarizes do something like > solution > 3 but with a module parralle to BrModuleMatchTrack.. I do not like the > root > file solution which would add a 3. method for storing calibration/db > information. > > flemming > ---------------------------------------------------------------- > Flemming Videbaek > Physics Department > Brookhaven National Laboratory > > e-mail: videbaek@bnl.gov > phone: 631-344-4106 > ----- Original Message ----- > From: "Pawel Staszel" <ufstasze@if.uj.edu.pl> > To: "Djamel Ouerdane" <ouerdane@nbi.dk> > Cc: "Brahms Devel List" <brahms-dev-l@lists.bnl.gov> > Sent: Monday, June 14, 2004 3:07 PM > Subject: Re: [Brahms-dev-l] T2-T3 matching > > >> Hi Djamel, >> You are right, it is very old file, and we certainly have to update >> both >> the parameter file and the part of the software >> which deals with it. >> Let me explain you how was it done for now and then we can decide >> about >> the updates. >> >> offsets5361_5972.FS contains matching parameters in ascii format for >> all > possible detector combinations in FS. >> BrFsTrackingModule utilizes only parameters for T2-T3 combination. >> Files > like offsets5361_5972.FS >> are generated using the stuff from ps_app/fs/receff is a first part >> of the > detector efficiency calculation. >> This calculation uses local tracks as an input and depends only on H1 >> and > H2 calibration. >> (the bad thing is that H1 and H2 calibrations depends on global >> tracking > but for T2-T3 we don't need it) >> In the mean time I moved from ascii to root format (see > ~ufstasze/effic/EfficParamFile.root). >> >> As for now I see the following 3 solutions: >> 1: update BrFsTrackingModule, so it can read root format files: the > advantage of this solution is that we don't >> have to update a lot. The disadvantage is however, that you generate > offsetes for all detector combinations >> but still these offsets have to be redone because of H1 and H2. >> 2. Extract from ps_app/fs/receff what is needed and create a dedicated > module for generating T2-T3 offsets only. >> Then it will depend only on the localtracks. >> We can decide about the format, or maybe, for this 8 float numbers we >> can > create a db entry. >> 3. Generate T2-T3 offsets at the same time when the other parameters > utilized in BrModuleMatchTrack are generated. >> The last solution would required some updates in BrModuleMatchTrack >> but I > thing that this solution would >> significantly simplified a book keeping and would made the whole >> analysis > process more solid >> (less possibility for a mistake). It would automatically took the > advantage of your latest updates (brat version 2.17.8). >> >> So, I vote for the 3rd solution. >> I can provide the updates but let us first agree on of how to proceed. >> >> Cheers >> Pawel. >> >> >> >> >> >> Djamel Ouerdane wrote: >> >>> Hello, >>> >>> I was checking the BrFsTrackingModule and I saw the following: FFS >>> and > BFS >>> tracks are combined by checking some matching between T2 and T3 >>> tracks. >>> The module still uses an offset file called >>> >>> trackmatch/offsets5361_5972.FS >>> >>> How good is that ?? runs 5xxx are almost prehistory compared to >>> 11xxx. >>> I guess this question is for Pawel. How did you generate this file ?? >>> >>> Djam >>> >>> >>> >>> >> >> >> >> _______________________________________________ >> Brahms-dev-l mailing list >> Brahms-dev-l@lists.bnl.gov >> http://lists.bnl.gov/mailman/listinfo/brahms-dev-l >> > > > _______________________________________________ > Brahms-dev-l mailing list > Brahms-dev-l@lists.bnl.gov > http://lists.bnl.gov/mailman/listinfo/brahms-dev-l > _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Tue Jun 15 03:49:41 2004
This archive was generated by hypermail 2.1.8 : Tue Jun 15 2004 - 03:50:03 EDT