sPHENIX tracking discussion

["Frawley, Anthony" <afrawley AT fsu.edu>]

Hello Christof and Haiwang,

How about changing the requirement in the seeding step to on that requires 1 or more INTT layers, all MAPS layers and the first TPC layer?

Tony

---

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Christof Roland <christof.roland AT cern.ch>
Sent: Saturday, April 29, 2017 4:35 PM
To: Haiwang Yu
Cc: sphenix-tracking-l AT lists.bnl.gov; David Morrison
Subject: Re: [Sphenix-tracking-l] Seeding/Tracking Efficiency

 

Hi Haiwang, 

On 28.04.2017, at 17:40, Haiwang Yu <yuhw.pku AT gmail.com> wrote:

Hi Christof,

This solves the mystery. I also observed similar thing in the full tracking.

After the fixing the bug in the track propagation on Tuesday, the track propagation performance has been improved a lot.

In both efficiency and speed. (Attached slides)

One remaining issue is the relatively low tracking efficiency (88% for cylindrical, 79% for ladder) in high multiplicity environments (1000 low momentum pions) that caused by this strict seeding requirements.

This we have to address next, obviously.

I tried to loosen the seeding requirement to 6/8, but I got many ghost even in 100 pion environment. (~200(seeds)/100(input)).

I am working on two things to make the seeding ghost in control:

• seeds cleanup - merge seeds

I had a closer look at the 6/8 seeds and it looks like it is less of a combinatorial problem, but the same seed is found multiple times with different hit combinations. There are many more seeds than true tracks, but from the gen reco matching we see almost all seeds have a good gen match with a high fraction of shared hits between gen and reco and also a good pt, eta and phi match between gen and reco.

We should really implement a seed merging strategy based on the hit pattern and hits shared between multiple seeds, as we talked about earlier this week. 

• eliminate track propagation if incremental chi2 consecutively large in several layers

Yes, this is the last big piece missing. In the track propagation we need to kill tracks that likely will not give a good track in the end but also allow multiple tracks to be generated from one seed. If the chi2 increment is too high hits should not be added to a trajectory and if a trajectory has too many holes or has traversed too many layers without good hit added, it should be flagged bad.

BTW, central Hijing events could be run, just consumes a lot of memory. (ana. 49, more than 18GB) I think reading in the DST nodes actually takes the bulk part. But GenFit is also heavy. Will seek help from Chris and Jin for that.

This indeed looks quite excessive. I hope Chris and Jin will be able to help.

cheers 

   Christof

On Fri, Apr 28, 2017 at 11:04 AM David Morrison <dave.patrick.morrison AT gmail.com> wrote:

Hi Christof,

That looks very encouraging – and makes sense too.

Dave

On 4/28/17 9:50 AM, Christof Roland wrote:
> Hi Everybody,
>
> I had a look at the seeding/tracking efficiency.
>
> As suspected in the last meeting it turns out that the seeding layers are not really hermetic.
> Especially the INTT layers are not 100% efficient, which is probably to be expected.
> This in turn means the the current seeding requirement of 8 out of 8 layers hit is
> responsible for a large part of the inefficiency we saw in the kalman tracking.
>
> Releasing the number of hit requirement in the seeding step from 8 out of 8 to
> 6 out of 8 hits increases the single track reconstruction efficiency from ~86% to ~98%
>
> Please see the attached plots below.
>
> In the region below 1 GeV the 6 out of 8 seeding scheme results in some segmentation
> violations. We'll have to take a look at that.
>
> Cheers
>
>    Christof
>
>
>
>
>
>
>
>
> _______________________________________________
> sPHENIX-tracking-l mailing list
> sPHENIX-tracking-l AT lists.bnl.gov
> https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l
>
_______________________________________________
sPHENIX-tracking-l mailing list
sPHENIX-tracking-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l

<KalmanPatRec_2017-04-28.pdf>