Problems with FDC reconstruction

[sdobbs]

Justin, Simon, and Thomas noted that there are few tracks reconstructed in the forward direction. Although the total number of FDC hits was basically consistent between the two simulations, there is a large difference in the number of hits matched to tracks. For example, we look at single protons with p=4 GeV/c at theta = 4 degrees [see: dc_hits.pdf]

Running the FDC_Efficiency plugin showed that the time distributions in the various packages were more-or-less similar, but the residual distributions were quite different, see for plane 1: resid2d.pdf

Could there be a rotation or other difference in geometry of the packages?

[zihlmann]

It is clearly an issue with the timing in the FDC. The two plots show the wirebased and timebased tracking of an event. The timebased tracking is off losing all CDC hits!

[sdobbs]

Attached are some distributions of the per-plane timing distributions for track hits from FDC_Efficiency. There is some differences in the gross timing distributions, which are not large, but maybe it could cause this effect. Thomas' study should give more complete results:

FDC cathode hit times: fdc_cathode_time.pdf FDC wire hit times: fdc_wire_time.pdf FDC pseudo hit times: fdc_psuedo_time.pdf

Blue: HDGeant, Red: HDGeant4

[T-Britton]

I have been digging into the FDC hit quantities and can say that the truth-hit quatities in geant3 and g4 look equivalent. This would seem to indicate it is not an effect of smearing or parameters in smearing being tuned to geant3 in particular. I am seeing some pretty striking differences in the d vs t distributions for Anode TRUTH hit times. Attached are the distributions for Layer 1, geant3 is the one annotated in red. The x-axis is time and the y axis is d from the FDCHit factory (DOCA). Also this sample contains no secondaries.

Firstly, in every layer with sufficient statistics in both G3 and G4 there seems to be a clustering of points labelled A. It occurs near .5 cm at small times (offset a bit from the starting t value for the main band. Since this is in both geant3 and geant4 I don't think this alone is the problem, but I don't understand why this is here. This bulge at low t (A) is always part of a fuzzy band (D).

The band labelled D is narrower in Geant3 but still there in Geant4. Once again, this is in both versions and probably not the cause, but I'd like to know why we have a band uncorrelated with time there.

At C we see what looks to be a cutoff in distance. For geant 3 it is a bit over .8 cm, but for geant4 it is a bit over .7 cm. While talking with Simon we think the natural cutoff for a sense wire's DOCA should be .5*sqrt(2) or ~.71 cm. Geant 4 gets this right but not geant 3?

Lastly, we come to B. There are two observed issues with B. Quite obvious is a band at .4 cm between 100->200 ns. This band does not exist for any layer of geant 4. Geant 3 has this problem on more than layer one; we see it in L1,L2,L7,L8. I want to confirm the pattern with 5 degree tracks but it seems the pattern is that the first two anode layers of a given block of three (a full set of 60 degree rotations) have this problem, then the next block of three do not, then the next two have the problem etc. Finally, The dark band represents the functional form of conversion between drift time and DOCA. While this changes with field we do not expect a clocking in the curve. Layer 1 (of the set of three) has more curvature, layer 2 (of the set of three) has less curvature, and layer 3 has the least. This pattern is reproduced across the entirety of the FDC. I am trying to produce a gif of these plots, which I will post when I manage to achieve it. It demonstrates this clocking behaviour readily

[rjones30]

Thomas,

I am looking in detail at the fdc hits generation in hdgeant and hdgeant4 now, and there are (different) bugs in each. I guess that both are buggy is no surprise, since I more or less copied the algorithm over when I created the FDC hits package in hdgeant4. In doing so, where I thought I was cleaning up some obtruse aspects of the code, I actually fixed bugs, but in the process produced other unintended features. More on this will follow soon. I would recommend that others NOT spend a lot of time examining the artifacts of the simulated fdc tracks in either hdgeant or hdgeant4 until I introduce some fixes to clear up the most egregious of these bugs, like the failure to calculate the DOCA correctly for about 50% of the hits in hdgeant3. That is much improved in hdgeant4, but then the cathode strips are out of kilter in that code. Working on all of this now.

-Richard Jones

On Fri, Jul 27, 2018 at 11:39 AM T-Britton notifications@github.com wrote:

I have been digging into the FDC hit quantities and can say that the truth-hit quatities in geant3 and g4 look equivalent. This would seem to indicate it is not an effect of smearing or parameters in smearing being tuned to geant3 in particular. I am seeing some pretty striking differences in the d vs t distributions for Anode TRUTH hit times. Attached are the distributions for Layer 1, geant3 is the one annotated in red. The x-axis is time and the y axis is d from the FDCHit factory (DOCA). Also this sample contains no secondaries. Firstly, in every layer with sufficient statistics in both G3 and G4 there seems to be a clustering of points labelled A. It occurs near .5 cm at small times (offset a bit from the starting t value for the main band. Since this is in both geant3 and geant4 I don't think this alone is the problem, but I don't understand why this is here. This bulge at low t (A) is always part of a fuzzy band (D). This is narrower in Geant3 but still there in Geant4. Once again, this is in both versions and probably not the cause, but I'd like to know why we have a band uncorrelated with time there. At C we see what looks to be a cutoff in distance. For geant 3 it is a bit over .8 cm, but for geant4 it is a bit over .7 cm. While talking with Simon we think the natural cutoff for a sense wire's DOCA should be .5*sqrt(2) or ~.71 cm. Geant 4 gets this right but not geant 3? Lastly, we come to B. There are two observed issues with B. Quite obvious is a band at .4 cm between 100->200 ns. This band does not exist for any layer of geant 4. Geant 3 has this problem on more than layer one; we see it in L1,L2,L7,L8. I want to confirm the pattern with 5 degree tracks but it seems the pattern is that the first two anode layers of a given block of three (a full set of 60 degree rotations) have this problem, then the next block of three do not, then the next two have the problem etc. Finally, The dark band represents the functional form of conversion between drift time and DOCA. While this changes with field we do not expect a clocking in the curve. Layer 1 (of the set of three) has more curvature, layer 2 (of the set of three) has less curvature, and layer 3 has the least. This patter is reproduced across the entirety of the FDC. I am trying to produce a gif of these plots, which I will post when I manage to achieve it. It demonstrates this clocking behaviour readily

[image: g3] https://user-images.githubusercontent.com/23260420/43328480-1972de06-918c-11e8-8a12-cd1ed96689b3.png [image: g4] https://user-images.githubusercontent.com/23260420/43328490-1cee421e-918c-11e8-8ea7-dc78cf48fe30.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/54#issuecomment-408457017, or mute the thread https://github.com/notifications/unsubscribe-auth/AHeFWPkRX_EHx-1fknBz3usd2o5-s-Omks5uKzQcgaJpZM4VT6hB .

[T-Britton]

Understood. For completeness here are 2 gifs with geant3 first:

[rjones30]

I just submitted a pull request that I believe resolves the core issue being reported here. There may be other issues remaining, but this fix should make the forward track efficiency comparable between hdgeant and hdgeant4.

What was the bug?

The code was copied pretty much line-for-line from the hdgeant fdc hits code, except that quantities like 3-vectors that are arrays in the c code become objects in the c++ code. Code conversion in this direction is usually pretty safe, but in this case there was a well-designed programmer's snare in the c code. Consider this brief block of code in hitFDC.c: if (AddFDCAnodeHit(ahits,layer,ipart,track,xwire,xlocal,dE,t, &tdrift)){ AddFDCCathodeHits(PackNo,xwire,xlocal[1],tdrift,n_p,track,ipart, chamber,module,layer,global_wire_number); } Looking at that, you see the same array xlocal being passed by pointer to AddFDCAnodeHit and then in the next line element 2 of the same array is passed to AddFDCCathodeHits. What is tricky about this is that AddFDCAnodeHit actually modifies the second element of the xlocal array, so that xlocal changes between the entry and return from AddFDCAnodeHit. Since this is supposed to be the DOCA that was computed earlier in the code, I never imagined that it might be overwritten by the anode wire hits code. WRONG.

Please pull this fix, rebuild, and check if this fixes this issue.

In debugging this, I came across several issues with the tracking that I think should be looked into at some point. One of them was in the hdgeant simulation itself, where the DOCA was incorrectly computed in the FDC for nearly half of the hits!! This has been submitted in a separate pull request. There are others that I might come back and look into at some later point, related to the failure of the tracking to correctly find the right way to thread the fdc hits left-right ambiguity, even when multiple scattering and decays are disabled. I also see very bad resolution in the fdc for large drift times when I look in the hdview2 track debugger. By very bad I mean like 700-800 microns sigma. I don't know if this is a bug in the event display or in the tracking, but I suspect the latter. For the time being I am leaving it alone because it appears the same way looking at either the hdgeant or hdgeant4 output.

[jrstevenjlab]

Thanks for the fix Richard. I ran a small sample of pions with p = 4 GeV and theta = 4 degrees in hdgeant4 after this fix (left) and before this fix (right), see below. With this fix to FDC hits in hdgeant4, the # of hits on tracks looks much more reasonable than the initial comparison that started this thread. We should wait for Thomas's G3/G4 comparison before closing the issue, but from a first look this certainly moves in the right direction.

[T-Britton]

Looks fine now... will be reopened upon final checks