[Hps-analysis] FEE Track Matched Clusters

Wed Oct 7 16:17:21 EDT 2015

Hi all,

Thanks for all the help.

I was still getting seed tracks mixed into GBL tracks. After cleaning all
of this out, I can see similar distributions to what Omar showed today and
everything is now within a few %. I can fine-tune the cuts from here.

-Holly

On Wed, Oct 7, 2015 at 4:11 PM, Nelson, Timothy Knight <
tknelson at slac.stanford.edu> wrote:

> Something is wrong with the GBL track states, in that the default track
> state (target) points to the hit in the last layer better than the track
> state at the last layer.  Obviously this is wrong, although I’m not sure
> yet whether the problem is with the track state at the target or the one at
> the last hit, or both.  I’ll be looking at this, although I’m amidst a
> broader review of the entire track reconstruction (with plans to overhaul
> major portions of it) which is taking up my time at the moment.
>
> In any case, extrapolation of the target track state is the best thing we
> currently have and extrapolation errors at the ECal are small compared to
> ECal cluster position resolutions anyway, so this shouldn’t be a serious
> issue (and certainly not one to explain Holly's E/p discrepancies).
>
> -Tim
>
> > On Oct 7, 2015, at 11:23 AM, Omar Moreno <omoreno1 at ucsc.edu> wrote:
> >
> > Final state particles are made out of both GBL and seed tracks.  The
> type of the particle (ReconstructedParticle of HpsParticle) is set to the
> type of the track so you should be able to select whichever tracks you want
> to use.  The momentum of the FS particle is equal to the momentum of the
> track associated with it.
> >
> > A word of caution, though; when extrapolating GBL tracks to the Ecal,
> the GBL track parameters at the target are used.  This is incorrect and, as
> a result, FS particles using GBL tracks may be mismatched to a cluster.
> What we really want to do is extrapolate the track using the GBL track
> parameters at the last layer with a hit in the SVT.  This requires some
> additional code which, I believe, Tim is working on.  Furthermore, we still
> haven't checked the agreement between the GBL tracks in Java and those
> obtained using the C++ refit.  Matt said the GBL tracks look fine so I'm
> assuming they are OK, but we should do a thorough comparison.
> >
> > --Omar Moreno
> >
> > On Wed, Oct 7, 2015 at 11:01 AM, Sho Uemura <meeg at slac.stanford.edu>
> wrote:
> > You could try making the plots with seed tracks and with GBL tracks. The
> GBL tracks should show better top-bottom agreement on momentum scale, and
> they should also show better resolution (tighter E/p distribution). If you
> see neither of those differences, there might be something wrong with the
> track type code.
> >
> > Yes, the new pass3 detector should make seed tracks and GBL tracks agree
> better. But bad things will continue to happen if somehow your analysis is
> using seed tracks instead of GBL, or a mixture of both.
> >
> > On Wed, 7 Oct 2015, Holly Vance wrote:
> >
> > So I re-ran my code checking that the track type is GBL, and the plots
> look
> > the same. It seems that these effects will be specifically addressed in
> > this upcoming pass.
> >
> > On Wed, Oct 7, 2015 at 12:25 PM, Nelson, Timothy Knight <
> > tknelson at slac.stanford.edu> wrote:
> >
> > So the GBL track isn?t used for this collection? (I though GBL ?healed?
> >
> > the v2 momentum scales).
> >
> > T
> >
> > On Oct 7, 2015, at 9:18 AM, Sho Uemura <meeg at slac.stanford.edu> wrote:
> >
> > SeedTracks in v2 geometry have big momentum shifts like what you're
> > seeing. GBLTracks have better momentum in v2 than in v1.
> >
> > We think this is because v1 has systematic misalignments across the
> > detector (e.g. L1-3 vs. L4-6), and v2's misalignments are due to
> > measurement error and are less correlated from sensor to sensor.
> SeedTracks
> > are very sensitive to alignment of the first layers of the SVT, so the
> > momentum measurement is worse in v2. GBLTrack momentum is in a sense
> > "averaged" over the length of the track, so the momentum measurement is
> > better in v2.
> >
> > SeedTracks are very sensitive to misalignment in
> >
> > On Wed, 7 Oct 2015, Nelson, Timothy Knight wrote:
> >
> > Hi Holly,
> >
> > It turns out the v2 (survey) alignment used in pass 2 is no better (and
> > possibly worse) than the v1 (as designed) alignment (the assembly error
> > appears to have been as small as or smaller than the survey error, where
> 50
> > microns is a big effect).  Nonetheless, you shouldn?t be seeing those
> > effects with either one, so something is obviously wrong.    I?m not sure
> > which track collection is used for the FP Particle collection, but our
> best
> > fits for FEE should have errors at the 1% level, not the 10% level, in
> both
> > top and bottom.
> >
> > Sho?  Omar? Pelle?
> >
> > Tim
> >
> > On Oct 7, 2015, at 8:20 AM, Graf, Norman A. <ngraf at slac.stanford.edu>
> > wrote:
> >
> > Good Morning Holly,
> > I?m sure the experts will also chime in, but I?d like to point you to
> > the presentations at
> > yesterday?s SVT meeting where there was quite a bit of discussion of
> > alignment.
> > https://confluence.slac.stanford.edu/display/hpsg/10.6.2015+Weekly
> > Omar had also shown some slides (not yet posted) from his analysis of
> > the v3
> > detector, which I assume he will be showing either tomorrow or Friday.
> > Norman
> >
> > From: Hps-analysis [mailto:hps-analysis-bounces at jlab.org] On Behalf
> > Of Holly Vance
> > Sent: Wednesday, October 07, 2015 7:24 AM
> > To: hps-analysis at jlab.org
> > Subject: [Hps-analysis] FEE Track Matched Clusters
> >
> > Hi,
> >
> > I analyzed the skimmed FEE events from pass 2 studying track matched
> > clusters at the Ecal. I made a very short summary in the attached pdf,
> and
> > I was wondering if anyone from tracking can comment on why the momentum
> for
> > these tracks is 10% high/low.
> >
> > How well do we know the SVT planes positions? I assume the survey
> > cannot tell us this precisely.
> >
> > -Holly
> >
> >
> > _______________________________________________
> > Hps-analysis mailing list
> > Hps-analysis at jlab.org
> > https://mailman.jlab.org/mailman/listinfo/hps-analysis
> >
> >
> > _______________________________________________
> > Hps-analysis mailing list
> > Hps-analysis at jlab.org
> > https://mailman.jlab.org/mailman/listinfo/hps-analysis
> >
> >
> >
> >
> > --
> >
> >
> >
> > _______________________________________________
> > Hps-analysis mailing list
> > Hps-analysis at jlab.org
> > https://mailman.jlab.org/mailman/listinfo/hps-analysis
> >
> > _______________________________________________
> > Hps-analysis mailing list
> > Hps-analysis at jlab.org
> > https://mailman.jlab.org/mailman/listinfo/hps-analysis
>
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> NOTE: This message was trained as non-spam.  If this is wrong,
> please correct the training as soon as possible.
>
> Teach CanIt if this mail (ID 03Pqkdk9s) is spam:
> Spam:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Pqkdk9s&m=075ad75b9f6f&t=20151007&c=s
> Not spam:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Pqkdk9s&m=075ad75b9f6f&t=20151007&c=n
> Forget vote:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Pqkdk9s&m=075ad75b9f6f&t=20151007&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/hps-analysis/attachments/20151007/bb931602/attachment-0001.html>