Dear Flemming and Ian, Yesterday we (Djamel and me) agree to do it exactly as suggested by Flemming. I will write a dedicated module for T2-T3 matching, which will be used in parallel to BrModuleMatchTrack. Cheers Pawel. Ian Bearden wrote: > 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 04:56:51 2004
This archive was generated by hypermail 2.1.8 : Tue Jun 15 2004 - 04:57:07 EDT