Re: [Brahms-dev-l] dst update ?

Hi Flemming,

> 
> I agree we need the 'closets points' as pointed out by Claus.Someone may
> have looked at this but so far I can tell it has not been made public.

If you recall, I have looked into this. Now, the closest points can be 
retrived from the matched track : 

  BrVector3D BrMatchedTrack::GetFidPoint()

As I said in an earlier email, the Y and X of this point are not 
necessarily correlated, they just give the closest X and Y, wherever they 
happen to be along the path in the magnetic field. I introduced a vector 
3D because I also wanted the Z for display. Remember:

brahms_app/do_app/track/trackmatchDisplay.C

if you want to visualize what's going on at the matching level. I looked 
at the closests points track by track and could see no problem in the 
algorithm.


> 
> 
> I think we can very soon do the official reco for the 200 GeV auau (ltr and
> gtr) now that Pawel and Tomasz has made most of the calibrations for the DC
> and completed  the 'automated way of generating the offsets for missing
> matchings
> (one issue here comes to mind namely that the fitted dang offsets DO depend
> on polarity, in FS this is not a problem, but in
> mrs we should really have independent offsets for POS and NEG settings.
> 


I think it can be easily done. One would have to slightly modify 
BrModuleMatchTrack and fill histograms depending on the momentum sign. As 
far as I could see, the histos hMatch<param>All are filled just after you 
evaluate p, so you already know the sign of p. Of course, in the FS, one 
set of histos would be almost empty. So one can make a case for MRS only.
It implies that one extra offset file should be written on the fly for 
the MRS. Who can do that ? I don't have time right now and I'm leaving for 
~ one week.


> We should make sure that there is enough information to possible
> re-evaluate theta,phi based on actual vertex chosen and cuts made there
> (recall the theta-vertex diff dependence).
> 
> SInce this is turning out to be an e-mail with several open issues regarding
> tracking and dst I will like to add that someone
> really should investigate the issue on TPC tracks close to the edge, by
> looking at e.g. T3 projected tracks back to T2 (T1)
> and determine an emperical correction at the hit-level (not the track-level)
> in an attempt to get rid of the 'apperent epeneces on
> position, and I believe resiual effects on acceptances at the smallest
> angles for any gicen setting.

yes, and no ugly hack as I introduced long ago :) But doesn't this problem 
originate from the cluster finding algo ? When you are on the edge, I 
guess you tend to fit cluster tails and the mean does not reflect the real 
mean...no ? I'm not a TPC expert but this is my naive guess.

DJam


-- 
Djamel Ouerdane ------------------------------------------o
|  Niels Bohr Institute      |  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


_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l