Skip to content

Tracking/TrackHitContributions/hit_matching: 2DStrip-compatibility.#23

Merged
ybedfer merged 4 commits into
mainfrom
2DStripCompatible
Apr 30, 2026
Merged

Tracking/TrackHitContributions/hit_matching: 2DStrip-compatibility.#23
ybedfer merged 4 commits into
mainfrom
2DStripCompatible

Conversation

@ybedfer
Copy link
Copy Markdown
Contributor

@ybedfer ybedfer commented Apr 13, 2026

i) Association efficiencies of 'p' and 'n' strips are histo'd independently, as well as simultaneous 'p&n'.
ii) r vs. z: 'p' and 'n' RecHits are combined to obtain precise 3D info. For the BarrelOuterTracker, this is achieved by retrieving WorldToLocal transforms from a TGeometry file.
Also: some cosmetics changes, e.g.: input filename, output to ROOT file.

Briefly, what does this PR introduce? Please link to any relevant presentations or discussions.

What is the urgency of this PR?

  • [ *] Medium

What kind of change does this PR introduce?

  • [* ] Bug fix (issue = processing of 2DStrip RecHits)

i) Association efficiencies of 'p' and 'n' strips are histo'd independently,
 as well as simultaneous 'p&n'.
ii) r vs. z: 'p' and 'n' RecHits are combined to obtain precise 3D info. For
 the BarrelOuterTracker, this is achieved by retrieving WorldToLocal transforms
 from a TGeometry file.
Also: some cosmetics changes, e.g.: input filename, output to ROOT file.
@ybedfer
Copy link
Copy Markdown
Contributor Author

ybedfer commented Apr 13, 2026

Hello,

This PR requires PR #1077 of `epic (eic/epic#1077).

This PR improves the processing of 2DStrip hits in the hit_matching script, which otherwise yields a bizarre parabolic shape for the r vs. z distribution of the BarrelOuterTracker:
r_vs_z 2DStrip

It also introduces a new feature, viz. the independent histogramming of the association efficiency of 'p' and 'n' strips:
AssociationEff 2DStrip

The processing of pixel (as opposed to 2DStrip) data keeps being unchanged:
r_vs_z pixel
AssociationEff pixel

In order to bring into play the special processing of 2Dstrip data, one needs to symlink a TGeometry file to hit_matching.geometry.root in the $PWD.

Note that concerning the association efficiency histo:

  • The so many hits obtained for MPGDBarrelRecHits and OuterMPGDBarrelRecHits are due to the factor 2 in # of entries from 'p' and 'n' RecHits × the factor 5 of the Multiple Sensitive SubVolume implementation of 2DStrip.
  • There is also here and there a larger fraction of associated outliers:
    • in the 2DStrip MPGDs: I guess it can be easily explained by the more difficult track reconstruction task when strips instead of pixels.
    • in the SiEndcapTracker: there, I don't know...
  • In the plots above, only the Barrel (as opposed to Endcaps) MPGDs are 2DStrip.

@ybedfer
Copy link
Copy Markdown
Contributor Author

ybedfer commented Apr 14, 2026

Note: I haven't followed the indentation style of the original file. For various reasons:

  • it's inconvenient, given the amount of nested loops,
  • it does not correspond to what's used in the rest of ePIC software.

@bschmookler
Copy link
Copy Markdown
Contributor

Hi Yann. Thanks a lot for updating this.

Should we update the README (https://github.com/eic/snippets/blob/main/Tracking/TrackHitContributions/README.md) to include the instructions for including the TGeometry file, and how to toggle the verbose flag and max number of events?

@ybedfer
Copy link
Copy Markdown
Contributor Author

ybedfer commented Apr 15, 2026

Hello,
I committed a new README.md.

While doing this I tried to execute the recommended (in README) procedure, viz.:

root -l -b -q hit_matching.C

to check that it still works now that I added arguments to the macro (since those have default values, there is a priori no reason that I shouldn't work). But then I got the following error:

Processing /local/home/bedfer/eicA/snjppets/Tracking/TrackHitContributions/hit_matching.C...
libedm4hepDict dictionary payload:741:7: error: field has incomplete type '::edm4hep::Vector3f'
      referencePoint{}; ///< Reference point of the track parameters, e.g. the origin at the IP, or the position  of the
      ^
libedm4hepDict dictionary forward declarations' payload:8:26: note: forward declaration of 'edm4hep::Vector3f'
namespace edm4hep{class  Vector3f;}
                         ^
_etc_..._etc_...

This, whether I execute my new version or the old one.

ybedfer added a commit to eic/epic that referenced this pull request Apr 22, 2026
#1077)

…ugh TGeometry.

This is in particular taken advantage by the "hit_matching" script.
  i) Numbering: starts @ 0 (this concerns layer and module).
ii) The name of layer and module nodes contains the word
"Layer"/"Module" .
iii) The name of the Sensitive Volume is "DriftGap" or for the 2DStrip
version,
    where there are Multiple Sensitive Volumes, "ReferenceThinGap".
Also, the angular aperture of CyMBaL used in segmentation is also
corrected.

### Briefly, what does this PR introduce? Please link to any relevant
presentations or discussions.

### What is the urgency of this PR?
- [* ] Medium

### What kind of change does this PR introduce?
- [ *] other: Required by PR#23 of `eic/snippets`
(eic/snippets#23).

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
@bschmookler
Copy link
Copy Markdown
Contributor

Hi Yann. I see this issue with the script in the main branch also. It seems to be a CLING issue. I was able to resolve it by compiling the script:

root -l -b -q hit_matching.C+

I'll check if it still works for the version here.

@bschmookler
Copy link
Copy Markdown
Contributor

bschmookler commented Apr 29, 2026

Hi Yann. The code seems to run file if I compile it (with the + option). I added this information to the README.

There were two warnings when compiling the code.

You had this:

double lpos[3], Ur, Vr;

Ur and Vr are only assigned inside if (geometry->WorldToLocal(...)). So, I initialized them to zero

You also had this:

double X, Y;

X is only assigned when pn == 0 and Y only when pn != 0. So, I again initialized them to zero.

If you think that is reasonable, then we can merge this into the main branch now.

Copy link
Copy Markdown
Contributor Author

@ybedfer ybedfer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

@ybedfer ybedfer merged commit d139336 into main Apr 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants