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

Hi Djam,

>
> >
> > 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 do recall you looked into this. What was done was to add this information
to the bdst class. there was also a problem
reflecting front vs back geometry that for small y-pos the residual would
not be correct.  The real solution is to have the
TPC eom somewhat corrected, but it is tricky due to the change of Vdrift
with run.
>
> >
> >
> > 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.
>
>
I think this is correct
who can do this ?

> > 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.
>
This is NOT the problem. I looked into this and reported at Oslo on this.
There is a clear additional effect over the
'lack of pads' most likely due to electrostatics, that severely effetcs
position out to 5 cm from the edge, much more that a
one or 2 pad correction.I may be that the gains at near pad are lowered and
that this could be a good part of the effect.
In any case I think this has to be investigated by t3->t2,t1 matching

flemming




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