sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting
- From: "Yasuyuki Akiba" <akiba AT rcf.rhic.bnl.gov>
- To: "'Frawley, Anthony'" <afrawley AT fsu.edu>, <sphenix-tracking-l AT lists.bnl.gov>
- Subject: Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting
- Date: Mon, 18 Jul 2016 21:58:44 -0400
Dear Tony,
> I have no desire (or ability, for that matter) to suppress any effort. Good.
> I note that we have two DC experts in the collaboration who have raised > serious concerns about the ability of a PHENIX-like DC to function in the > sPHENIX environment. We understand this, and I also thought that DC was not an option until a few months ago. The particle density is much higher than PHENIX DC and it is certainly a challenge to reconstruct tracks in such high multiplicity environment. One the other hand, as I explained in my slides, the basic idea of the proposal is that the tracks are reconstructed by EMC-MAPS-SiStrip and then associated with DC hits to improve the momentum resolution. A realistic simulation will tell us how well this scheme works.
I should also explain that a main point of the idea is to separate the function of tracking into two. 1) Silicon tracker near the beam pipe for precision vertex measurement of b-tragging (internal Si trakcer) 2) A large tracker just in front of the EMCAL to improve the momentum resolution (outer tracker) In this configuration, if the internal silicon tracker has sufficient number of layers and size to reconstruct momentum of track at a reasonable resolution, one can association the internal track with the outer tracker even if there is a large gap between them. This is because you can use two information – positon and momentum vector --- for the association.
In this configuration, the outer tracker can be thin. It should have multiple layers since one need to get the vector information of the track, which is critical to connect the internal track and the external track. Once the track connection is done, the momentum resolution is determined by the position resolution of the outer tracker and the angular resolution of the internal tracker. Thus the outer tracker don’t need to extend to small radius to achieve 100 MeV mass resolution of Upsilon.
These point have already been demonstrated by full G4 simulation. The simulation by Gaku has demonstrated that combination of a compact silicon tracker (12cm outer raidus) and a thin outer track just in front of EMCAL can achieve ~94 MeV resolution of Upsilon in p+p. Please also note that The model used for the simulation is deliberately minimum. I determined the parameters of the model by a back-of-the-envelope calculation so that it can achieve mass resolution of Upsilon just below 100 MeV. Gaku’s simulation confirmed my calculation. We can improve the mass resolution if we want.
Note that this scheme is a generic one. The outer tracker in the scheme can be anything that serves our purpose. The requirement of the outer tracker is that they can be associated with the internal tracker and it has sufficient position resolution to achieve desired upsilon resolution.
The outer tracker can be TPC. But you don’t need to make it down to R=30cm. You can make a think TPC just in front of EMCAL with a small number of tracking layers. This would make a substantial saving of the cost compared with the 200K channel TPC covering that occupies R=30 to 80cm. Also, since the TPC starts at large radius, the technological challenge to the TPC is much reduced --- you don’t need to deal with the high particle density at R=30 cm.
The outer tracker can also be a pad chamber, as Tom suggested. I think we need two layers to get vector information of the track, which is critical for track association, and also important for redundancy.
And I think the outer tracker can be DC. The attractive thing of this option is that the cost of the DC is most likely lowest among those three options. There are, of course, challenges to make the DC works in the high multiplicity environment and to demonstrate that we can reconstruct tracks with EMC-internal Silicon tracker-DC combination. But this will give the largest cost reduction of the tracker, and I don’t see any show stopper at this point. For example, Tom warned about the inclination angle of low pT track that can increase the occupancy. As I wrote in the previous reply, this is well within what I considered.
Sincerely yours, Y. Akiba
From: Frawley, Anthony [mailto:afrawley AT fsu.edu]
Dear Yasuyuki,
I do not yet have a firm opinion about the viability of the proposal, and I am content to wait on the results of realistic simulations. I have no desire (or ability, for that matter) to suppress any effort.
I note that we have two DC experts in the collaboration who have raised serious concerns about the ability of a PHENIX-like DC to function in the sPHENIX environment. It would make no sense for the collaboration to ignore this. Those concerns can only be allayed by the results of realistic simulations, analyzed by a realistic tracking code, showing that your proposed detector can do the entire sPHENIX physics program.
That will be a big job, and I do remain skeptical that you can make a firm case in 7 weeks. That is based on my experience, and may just be wrong - but I would be pleased if it turns out that way.
Cheers Tony
From: Yasuyuki Akiba <akiba AT rcf.rhic.bnl.gov>
Dear Tony,
First, the main point of my previous message is to correct a factual error. What you wrote in the minutes is factually incorrect. The correct description is what I wrote.
> In my opinion, we are well beyond the stage in the project where these kinds of qualitative arguments are useful.
We have already shown that the concept works well in p+p. Gaku did it with full G4 simulation. The Upsilon mass resolution better than 100 MeV is achieved.
Gaku also has shown that the concept works in semi-realistic simuation and shows that Upsilon 3 states are separated in central HIJING event.
Since the current reconstruction program is not seated for the proposed detector concept, we need to write an appropriate track reconstruction code. Gaku is working on it. Once the code is complete we will show the efficiency and fake rate of the proposed tracker.
I should also point out that the proposal is very flexible. The proposed DC has only 6 layers. This is basically the minimum number of layers that I think I need. We can easily increase the number of layers with small cost increase.
I must say that I am very disappointed with your response during the meeting. As the convener, you should be open all options. You should not suppress the effort based on your own prejudice. You said you don’t believe that we can do realistic simulation in 7 weeks. On what ground you said that? Isn’t it your prejudice?
I proposed this option since I think this is a viable and very inexpensive alternative to TPC. The cost to build the proposed DC is a very small fraction of that of TPC. The number of read-out is much smaller (3K for 6 layers, 6K for 12 layers compared with 100K to 200K channels of the TPC). The detector volume is small. Since it is placed just in front of EMCAL, we can make a back wall to support and some supports in the front window with little effect in tracking performance. The technology is quite conventional. If this works, it basically solve all of the descoping issue of sPHENIX.
You probably say that you don’t believe this is a viable alternative. If so, why do you think so. We are middle of to make a realistic simulation of the detector. So we don’t show results of realistic simulation yet. But this also means that you have no ground to judge this option to be viable or not. Only when you see the results of realistic simulation you can judge. Therefore, before we showed realistic simulation results you should not make any prejudice or pre-judgement.
You can of course ask any specific question to the proposal. I am happy to answer.
Sincerely yours, Y. Akiba
From: Frawley, Anthony [mailto:afrawley AT fsu.edu]
Dear Yasuyuki,
In my opinion, we are well beyond the stage in the project where these kinds of qualitative arguments are useful.
To show that your concept is a viable tracker for sPHENIX, you would need to show, in realistic simulations, that it can find ALL tracks in a central Hijing event with excellent efficiency, while achieving good track purity and good enough momentum resolution. Otherwise it does not meet the requirements of the entire physics program.
There is a major effort going on to realistically evaluate the TPC + MAPS performance in these areas. Any judgement about whether the tracker you have proposed is a viable alternative to the TPC could only be made based on a comparison of performance between the two trackers that is provided by similarly realistic simulations of both.
Best regards Tony
From: Yasuyuki Akiba <akiba AT rcf.rhic.bnl.gov>
Dear Tony
> He presented some best case (i.e. overly optimistic) simulations > of charge detected in a 2 mm drift region in the DC showing that > about 1/3 of the time the high momentum track is missed.
What Tom showed is that when a 200 MeV track, which makes 6mm long electron cloud in the 2mm sampling region due to the large inclination angle, overlap with a high pT track, the signal peak from the high pT track is lost at 30% probability in his definition of “lost”. His definition of “lost” is that the pulse height of the 200 MeV background hit exceeds that of the high pT track.
I should point out that number of 200 MeV track is small. And the long (6mm) cloud is due to the fact that 200 MeV track is almost at the limit of PT acceptance. The track with pT<180MeV/c doesn’t reach to the DC (R>80cm). So what Tom has done is to take an extreme case that a low pT track with a long background tail coverlap with high pT track. Even this rare case, he showed that 70% of the time, one can find the signal peak of the high pT track. So basically what he showed confirmed what I have been saying. Pulse height information helps two track separation.
I should also point out that his criterial of “lost” is not a right one. For my purose, “found” should be that I can se leading edge produced by the high pT track. In this definition, the “lost” probability should becomes smaller value.
Tom didn’t consider the probability of such overlap happens. The average <PT> of charged particles in Au+Au collisions is >0.5 GeV/c. The inclination angle of a 0.5 GeV/c track is about 0.4 radian, and the length of electron cloud produces by such a track is about 1mm. The average distance of the track in the DC is about 1cm. So the occupancy is 10% if the two track separation is 1mm. It is 15% of the two track separation is 1.5mm, which is the official number of PHENIX DC. It is written in a NIM paper that PHENIX DC can separate two track at 1.3mm at 50% probability. Ed O’Brien calculated the occupancy to be 20% with dN/dy=750 and 1.5mm separation in his notes, and Tom agreed with this 20% number. So even if I use Ed’s number 80% of the time the hit of the track of interest is clean from overlap.
As I wrote in one of my previous message, and also in my presentation, what I need is to have a few such clean hits free from overlap with background track. In the prosed DC, there are 6 anode layers. If the occupancy is 10%, 98% of track of interest has at least 4 such clean hits. Even if the occupancy is 20%, 98% of track has at least 3 clean hits. These 4 or 3 hits are all I need to confirm the track and to measure its position.
I can also increase the number of layers. The total number of read-out channel of the proposed DC is only 3K channel (3K of 8bits FADC). I can easily double the layer with a very modest cost increase. This makes the number of layer to be 12. I think this will give a very robust tracking even if the occupancy is 20% or even at 30%. If we have 12 layers, the probability that a track as at least 7 clean hits is 98% for 20% occupancy. Even with 30% occupancy a track should have 5 clean hits at 99% probability.
Sincerely yours, Y. Akiba From: sphenix-tracking-l-bounces AT lists.bnl.gov [mailto:sphenix-tracking-l-bounces AT lists.bnl.gov] On Behalf Of Frawley, Anthony
Hi All,
|
-
[Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Frawley, Anthony, 07/15/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Yasuyuki Akiba, 07/15/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Frawley, Anthony, 07/15/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Yasuyuki Akiba, 07/15/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Frawley, Anthony, 07/16/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Yasuyuki Akiba, 07/18/2016
- Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting, Edward Kistenev, 07/19/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Yasuyuki Akiba, 07/18/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Frawley, Anthony, 07/16/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Yasuyuki Akiba, 07/15/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Frawley, Anthony, 07/15/2016
-
Re: [Sphenix-tracking-l] Minutes of July 15, 2016 tracking meeting,
Yasuyuki Akiba, 07/15/2016
Archive powered by MHonArc 2.6.24.