[G12] Track Inefficiencies - Possible Drift Chamber Issue

[Michael C. Kunkel]

Greetings,

My map uses a | tpho + tprop - scVertexTime|<1ns
Where scVertexTime uses an input of mass to calculate betta
     double beta = p/sqrt(p*p + mass * mass);
     scVertexTime = tbidptr()->sc_time - scPathLen()/(LIGHTSPEED*beta);

I do not use ST to do timing cuts.

BR
MK
----------------------------------------
Michael C. Kunkel, PhD
Forschungszentrum Jülich
Nuclear Physics Institute and Juelich Center for Hadron Physics
Experimental Hadron Structure (IKP-1)
www.fz-juelich.de/ikp

On 27/07/15 19:28, Lei Guo wrote:
> The TOF paddles are knocked out manually, so you need the paddle IDs…. 
> In fact, rafael just produced another list of additional new bad 
> paddles. MK is rederiving his track efficiency correction map.
>
> To check if the drift chamber wire efficiency map has been applied 
> correctly, you need to compare the lab theta, and phi distributions by 
> sectors.
> Do you account for the number of good events you throw away with the 
> kinematic fitting CL cut? That percentage that we throw away with CL 
> cut is not entirely consistent with the simulation, and you have to 
> correct  for that as well. Or maybe you have already done that?
> Another thing one might have overlooked is that if one uses start 
> counter timing. I don’t know if MK’s map is derived after applying the 
> |Stvtime-RFvtime|<1ns cut. SO, it may or may not affect you. The 1ns 
> cut will throw away good events (ST resolution is not ~400ps), and 
> since the ST resolution is not simulated, you have to account for 
> that. However, it really depends on whether the map was derived with 
> the ST timing cut or not.
>
> Lei
>
>
> Lei Guo
> Assistant Professor
> Physics Department
> Florida International University
> Miami, FL
>
> email: leguo at fiu.edu <mailto:leguo at fiu.edu> or lguo at jlab.org 
> <mailto:lguo at jlab.org>
> Office:305-348-0234
>
>> On Jul 27, 2015, at 9:53 AM, Michael Paolone <mpaolone at jlab.org 
>> <mailto:mpaolone at jlab.org>> wrote:
>>
>> Hey Volker,
>>
>> The behavior is odd indeed.  I have some thoughts, but before I jump into
>> them, let me know what your channel is exactly and how you indentify it.
>> Is it pi+, pi- and p detected, with a missing pi0 you cut on?  Is it a
>> kinematic fit to the missing pi0?
>>
>> An overall thought: Have you looked at the distribution of each detected
>> particle in the DC (in x,y) at that specific energy to see if you can
>> "see" any strange holes or behavior?  Then you could see how it compares
>> to simulation.
>>
>> -Michael
>>
>>
>>> Hi Everybody,
>>>
>>> I know that we are all working on finalizing various g12 analyses.
>>> However, we found a serious issue with our γp → pω cross section 
>>> that
>>> currently prevents us from moving on. We are somewhat stuck and it may
>>> affect the whole run group.
>>>
>>> The attached pictures show the 3Ï€ invariant mass for the energy range
>>> 1650 - 1700 MeV and for forward angles of the 3π system. A nice ω peak
>>> is visible and a massive hole on the right side of the peak. This 
>>> hole is
>>> not supposed to be there (unless somebody has a good physics argument).
>>> The energy range is probably very low for most of the g12 analyses.
>>> However, the hole will slowly move to higher masses with increasing 
>>> photon
>>> energy but it will not disappear. The other two pictures show the same
>>> distribution if one (1) uses events where only sectors 1, 3, 5 triggered
>>> or alternatively, (2) only sectors 2, 4, 6 triggered.
>>>
>>> We assume the effect is based on track inefficiencies, perhaps dead
>>> regions in the drift chamber. In principle, Michael Kunkel’s "trigger
>>> map" should account for this since his approach is based on 
>>> comparing two-
>>> and three-track events, i.e. it combines trigger and track 
>>> inefficiencies;
>>> the idea is good. In our analysis however, this trigger map leads to an
>>> overall disagreement with the g11 ω cross section, whereas Zulkaida's
>>> current cross section is in fair agreement with g11 but exhibits certain
>>> problematic regions, e.g. the forward direction. These holes in the mass
>>> distributions are not accounted for by the Monte Carlo simulations 
>>> and we
>>> assume the effect is not in the MC.
>>>
>>> We have a few questions we would like some help with (and need to 
>>> find an
>>> answer for).
>>>
>>> 1) Since it is still possible that the problem is at our end, would
>>> anybody be able to reproduce this problem for us? The effect is so big
>>> that even a quick and dirty look at it, will probably work.
>>>
>>> 2) We tried to knock out dead TOF paddles as suggested in the analysis
>>> note. The paddle numbers are available in the data. However in the Monte
>>> Carlo, the numbers appear to be available only for the proton and 
>>> not for
>>> the pions. Has anybody else noticed this issue? How do others knock out
>>> the paddles in the MC? Or is this done automatically? It is difficult to
>>> do this based on measured angles since two particles with the same polar
>>> and azimuthal angles, one produced at the beginning of the target 
>>> and one
>>> at the end, may hit different TOF paddles. The g12 target was very long.
>>>
>>> 3) The Monte Carlo “gpp" options given in the analysis note do not
>>> reproduce the holes in the mass distributions. For this reason, we 
>>> do not
>>> know if dead wires are actually simulated and to what extent. Can 
>>> anybody
>>> comment on this?
>>>
>>> This problem shows up in the γp → pω channel but we are 
>>> concerned that
>>> it may also affect the two-pion channel we are analyzing, perhaps not as
>>> holes in mass distributions but as general track inefficiencies in 
>>> certain
>>> regions of the drift chamber. In the latter case, it would extremely
>>> difficult to notice. If so, it can potentially affect any reaction that
>>> uses Monte Carlo for the acceptance correction. My understanding is that
>>> we partially use the pω and the KΛ cross sections to make sure 
>>> that the
>>> g12 MC, trigger, etc. is working correctly.
>>>
>>> Best wishes,
>>>
>>> Volker
>>>
>>>
>>>
>>> _______________________________________________
>>> G12 mailing list
>>> G12 at jlab.org <mailto:G12 at jlab.org>
>>> https://mailman.jlab.org/mailman/listinfo/g12
>>>
>>
>>
>> _______________________________________________
>> G12 mailing list
>> G12 at jlab.org <mailto:G12 at jlab.org>
>> https://mailman.jlab.org/mailman/listinfo/g12
>
>
>
> _______________________________________________
> G12 mailing list
> G12 at jlab.org
> https://mailman.jlab.org/mailman/listinfo/g12

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/g12/attachments/20150728/80c6b911/attachment-0001.html>