Skip to Content.
Sympa Menu

sphenix-maps-l - Re: [Sphenix-maps-l] In-time vertexing with INTT

sphenix-maps-l AT lists.bnl.gov

Subject: sPHENIX MAPS tracker discussion

List archive

Re: [Sphenix-maps-l] In-time vertexing with INTT

Chronological Thread  
    < Chronological >       < Thread >
  • From: sookhyun lee <dr.sookhyun.lee AT gmail.com>
  • To: Sanghoon Lim <shlim AT rcf.rhic.bnl.gov>
  • Cc: sphenix-maps <sphenix-maps-l AT lists.bnl.gov>, sphenix-intt-l AT lists.bnl.gov
  • Subject: Re: [Sphenix-maps-l] In-time vertexing with INTT
  • Date: Fri, 2 Nov 2018 00:29:39 -0500
Hi Sanghoon,

Correct on the first question.
On the second comment, this is exactly why I want to see if I can improve rejection factor by adding more layers and if going for 5um shaping time is feasible.

Best,
Sookhyun

On Fri, Nov 2, 2018, 00:18 Sanghoon Lim <shlim AT rcf.rhic.bnl.gov wrote:
Hi Sookhyun,

Thanks for the reply. Just to be clarify for me, in case of the 97% out-of-time vertex rejection shown in the page 3, dose that means 3% out-of-time vertices are tagged as in-time vertices?

I have been using  the macro in master repository and it still has a timing window of 2um. 
We can increase the timing window to the maximum electronics shaping time of 5um in case we want to maximize the trigger efficiency, but I'd rather test vertexing module with multiple layers and see if it can improve out-of-time rejection.
I also notice that it's back to +/-2 um in the 'G4_Tracking.C' macro. If the +/-5 um of timing window is correct one we need to use, my point is that the number of out-of-time events in MVTX will be x2.5 than the case of +/2 um. Therefore the number of mis-tagged vertices (tagged as in-time event but true out-of-time event) per event may become larger with a same out-of-time vertex tagging efficiency.

Best,
Sanghoon

On Nov 1, 2018, at 10:52 PM, sookhyun lee <dr.sookhyun.lee AT gmail.com> wrote:

Hi Sanghoon, 

The fake rate as you define it would be the same as "1-rejection factor" in my slides. Each true vertex will tagged as either in-time or out-of-time and nothing in between. The integrated rejection factor is 97.x % when I use reconstructed vertices as well. 

I have been using  the macro in master repository and it still has a timing window of 2um. 
We can increase the timing window to the maximum electronics shaping time of 5um in case we want to maximize the trigger efficiency, but I'd rather test vertexing module with multiple layers and see if it can improve out-of-time rejection.

Best,
Sookhyun  

 

On Thu, Nov 1, 2018 at 10:56 PM Sanghoon Lim <shlim AT rcf.rhic.bnl.gov> wrote:
Hi Sookhyun,

Thanks for the update slides, and it's quite useful. Can you also make the fraction of true out-of-time vertices in the tagged vertices as in-time vertex (fake rate)?  Although your purity seems quite high (97.5% in page 6), but the number out-of-time vertices much larger than the number of in-time vertices in the 10 MHz collision rate. It would be useful to check the fraction of fake not only checking correct tagging efficiency.

One more thing is that do you use +/-2 us timing window for MVTX (based on your slide 6)? I think the macro has been updated to use +/-5 us timing window.

Best,
Sanghoon


On Nov 1, 2018, at 9:24 PM, mxliu <ming AT bnl.gov> wrote:

HI Sookhyun,
Very nice work. A few comments:
How many INTT hits do you require for each tracklet?  In your previous study, you only used one INTT hit to reject out of time tracks. 
 
Slide #3, do you also have the in-time track multiplicity distribution? 
 
Cheers,
Ming
-- 
Ming Xiong Liu
P-25, MS H846                     TEL:505-667-7125 
Physics Division                             631-344-7821(BNL)
LANL                                               630-840-5708(FNAL)
Los Alamos, NM 87545      FAX:        505-665-7020
 
 
From: sPHENIX-MAPS-l <sphenix-maps-l-bounces AT lists.bnl.gov> on behalf of sookhyun lee <dr.sookhyun.lee AT gmail.com>
Date: Thursday, November 1, 2018 at 10:57 PM
To: Sanghoon Lim <shlim AT rcf.rhic.bnl.gov>
Cc: <sphenix-intt-l AT lists.bnl.gov>, sPHENIX-MVTX <sphenix-maps-l AT lists.bnl.gov>
Subject: Re: [Sphenix-maps-l] In-time vertexing with INTT
 
Hi all,
 
Please see below for plots I have so far. I tried to be as clear as possible in defining quantities I plot and to incorporate all the comments received. 
 
 
The condor jobs have been running very slowly recently and I couldn't get to run more iterations. As a result, there are still some missing plots. Also, I still use Pythia min-bias files I generated for pile-up backgrounds due to technical issues. I do not see any significant change from switching to sanghoon's files, though I can try at next iteration. 
 
To answer some remaining questions, I do not refit vertex after adding INTT clusters as we will get the best vertex information when using triplets (not only because they give us the best resolution, but also the interaction vertex position information gets distorted as a track traverses through detectors.) What will be interesting is that you can propagate a track all the way out and then come back into the inner most layer, at which point the fit results will give us more meaningful information.
 
Track seeding efficiency with 1 INTT layer is >95% as stated here (slide 3):
 
 
Best regards,
Sookhyun   
 
 
 
 
 
On Fri, Oct 19, 2018 at 10:59 AM Sanghoon Lim <shlim AT rcf.rhic.bnl.gov> wrote:
Hi Sookhyun,
 
Thanks for your update, I had a couple of questions for clarification.
 
- What's the in-time events? Is this pythia or single particle generation?
- Event multiplicity is the number of charged tracks in generation level or the number of reco tracklets used for seed vertexing?
- Can you also find your tracklet finding efficiency? (This may affect the seed vertex resolution)
- I think you showed the seed vertex resolution before, can you also include that of recent version?
 
Best,
Sanghoon


On Oct 18, 2018, at 11:28 PM, sookhyun lee <dr.sookhyun.lee AT gmail.com> wrote:
 
Hello all,
 
Please find my updates on in-time vertexing with INTT at:
 
The results shown used  ~15% of intended statistics due to limited time and computing resources. 
Plots will be updated tomorrow morning again with more statistics. 
 
Best regards,
Sookhyun
 
 
 
 
 
 
On Tue, Oct 9, 2018 at 5:10 PM sookhyun lee <dr.sookhyun.lee AT gmail.com> wrote:
Hi Xin,
 
Please find my answers inline. 
Best regards,
Sookhyun

 

On Tue, Oct 9, 2018, 15:21 Xin Dong <xdong AT lbl.gov> wrote:
Hi Sookhyun,
 
Thank you for this nice study. Let me back off a bit and ask a couple of basic questions first.
 
Can you elaborate the definition of "in-time vertex identification efficiency"? My understanding from the slides is the probability of reconstructed vertices with 3 MVTX+1 INTT to be the truth MC vertices. I may be wrong here, and would appreciate your clarification.
 
So the module reconstruts all possible vertices in an event and uniquely determines an in-time vertex and assigns 0 to vt for this vertex. For each event, if at least one true in-time vertex has a reconstucted vertex with vt=0, we declare an in-time vertex is identified. The denominator is the number of events with in-time vertex with true vertex within 10 cm. 
 
 
What is the minimum number of tracks requirement in the vertex algorithm?
 
I require 2 track at minimum.
 
 
Do you also have the vertex finding efficiency? Fraction of MC truth vertex that got reconstructed. May be also interesting to see this vs. event multiplicity at different luminosity levels.
 
I'd like to refer you to the talk I gave in last year's collaboration meeting.
 
 
I tend to agree with Ming that 3 MVTX hit seems to be a bit tight. What if there are some small amount of dead areas on each layer of MVTX during the real operation. The dead area fractions in three layers will add up if we have the 3-hit requirement. This may cause some sizable vertex finding efficiency loss, isn't it?
 
This is very interesting question. In a catastrophic case of most sensors of 1 MVTX layer dead, I can naively imagine writing a 2D xy vertexing algorithm for phi segmented layer, which may be unnecessary. For z segmented layer, we can fit tracks to a line on xz plane, but the resolution won't be as good as a track won't be really straight. However, this is an unlikely circumstance as Tony points out. 
 
 
Thank you and Best Regards
 
/xin
 
 
 
 
On Tue, Oct 9, 2018 at 11:00 AM sookhyun lee <dr.sookhyun.lee AT gmail.com> wrote:
Hi Ming,
 
Yes, so far I only used 1 INTT layer to discriminate against out-of-time events. We certainly should reconstruct tracks using 2 MVTX hit + (2+) INTT hits at next iteration, but 2 MVTX hits only won't provide good starting curvature (for phi segmentation) or z0 parameter (for z segmentation) for INTT, thus cannot be used for in-time vertexing. I did not apply any pT cut on tracks used for vertexing.
 
Best regards,
Sookhyun  
 
On Tue, Oct 9, 2018 at 12:14 PM Ming Liu <ming AT bnl.gov> wrote:
Hi Sookhyun,
Nice work! So in your analysis, only one INTT hit was used to tag in-time association to a MVTX triplets? How about if you only use MVTX tracklet with two hits only? Have you applied any minimum momentum cuts?
 
Cheers 

Ming

Sent from my iPhone


On Oct 9, 2018, at 9:52 AM, sookhyun lee <dr.sookhyun.lee AT gmail.com> wrote:

Hello everyone, 
 
Please find my updates on in-time vertexing with INTT below.
 
 
Let us have discussions tomorrow at Inner tracking task force meeting as well.
 
Best regards,
Sookhyun
_______________________________________________
sPHENIX-MAPS-l mailing list
sPHENIX-MAPS-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-maps-l
_______________________________________________
sPHENIX-MAPS-l mailing list
sPHENIX-MAPS-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-maps-l

 
-- 
===========================
Xin Dong
Staff Scientist, Nuclear Science Division
Lawrence Berkeley National Lab
MS70R0319, One Cyclotron Road
Berkeley, CA 94720, USA
Tel: +1-510-486-4121
Email: XDong AT lbl.gov
===========================
_______________________________________________
sPHENIX-MAPS-l mailing list
sPHENIX-MAPS-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-maps-l
 
_______________________________________________ sPHENIX-MAPS-l mailing list sPHENIX-MAPS-l AT lists.bnl.govhttps://lists.bnl.gov/mailman/listinfo/sphenix-maps-l



Archive powered by MHonArc 2.6.24.

Top of Page