MPGDTrackerDigi: Multi-SensitiveVolume solution for the 2D-strip read…

[ybedfer]

…out.

Briefly, what does this PR introduce?

A solution to the issue of MPGD hits missing in track fit raised by Barak Schmookler in "https://indico.bnl.gov/event/27589/contributions/105659/attachments/60986/104773/tracking1_040325.pdf".

What kind of change does this PR introduce?

• [*] Bug fix

Please check if this PR fulfills the following:

• [ *] Tests for the changes have been added

Does this PR introduce breaking changes? What changes might users need to make to their code?

Breaking changes if and only if special "-PMPGD:SiFactoryPattern" option is specified and set != 3.

Does this PR change default behavior?

No.

[ybedfer]

This is a solution to the missing MPGD 2D-strip hits which was identified in April.

The issue was discussed at the track&vertex meeting of July, see "https://indico.bnl.gov/event/29024/contributions/110567/attachments/63655/109264/Bedfer_EPIC0724.pdf", where several solutions were proposed.

In this PR, I want to implement a solution based on a splitting of the sensitive volume, see comment in "https://github.com/eic/EICrecon/blob/MultiSensitiveMPGD/src/algorithms/digi/MPGDTrackerDigi.cc".

It's the only solution, of all those proposed, that I have been able to implement. I would call it a ugly solution: very complicated. But it is has the advantage of being a working one, as evidenced by the following plot of the hit-to-track association efficiency obtained from (a modified version of) the macro of Barak:
hit_matching.PR.pdf

This result is obtained if and only if are used:

• A new version of the epic library, with modified .xml and .cpp files for the Barrel MPGDs.
• Option -PMPGD:SiFactoryPattern=0.
• A modified version of TrackerMeasurementFromHits (not included in the present PR).

Given that the above-mentioned conditions are not met by default, the commit will not affect the standard execution of eicrecon in any way.

The roadmap for the full commit, that will enable the Multi-SensitiveVolume solution:

• A new epic library, with Multi-SensitiveVolume XML files and backward-compatible detector constructors (in store: see "https://github.com/eic/epic/tree/Multi-SensitiveVolume-MPGD").
• A new version of TrackerMeasurementFromHits (without which the outer barrel efficiency is null), also backward compatible (to be prepared).
• If all goes fine, one would have to make Multi-SensitiveVolume the default, implying simultaneous changes to epic and eicrecon ( -PMPGD:SiFactoryPattern=0).

But in any case, I would like to have a feed-back from the ePIC software community on my solution: is it satisfying enough to be committed (at least temporarily)? What kind of checks, in addition to the association efficiency shown above, should I perform?

More on the hit-to-track association: When one zooms on the efficiency histogram, some imperfections show up, viz.:

• Fewer 'p' hits than 'n' hits, particularly for the inner barrel.
• Some inefficiency.
• Some outliers.
  See the following plot:
  hit_matching.PR.zoom.pdf
• In fact, 'p' and 'n' hits need not be in equal number: they may depart in the accumulation step, whereby hits falling on a same cellID are lumped together. That it is the case more often for 'p' than 'n' in the inner barrel can be traced to the fact that there, the two coordinates are very different (orientation along φ or Z). In the outer barrel, the two coordinates are symmetric and they should be in equal numbers. But there, the unbalance is small and may be due to chance.
• I would still have to investigate the inefficiency and the outliers...

[ybedfer]

A question to c++ experts:
One of the compilation checks launched by the PR returns the following warning:

/home/runner/work/EICrecon/EICrecon/src/algorithms/digi/MPGDTrackerDigi.cc:288:24: error: possibly dangling 
reference to a temporary [-Werror=dangling-reference]
  288 |     const TGeoHMatrix& toRefVol = refVol.nominal().worldTransformation();
      |                        ^~~~~~~~
/home/runner/work/EICrecon/EICrecon/src/algorithms/digi/MPGDTrackerDigi.cc:288:71: note: the temporary was 
destroyed at the end of the full expression 'refVol.dd4hep::DetElement::nominal().dd4hep::Alignment::worldTransformation()'
  288 |     const TGeoHMatrix& toRefVol = refVol.nominal().worldTransformation();
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~

I did modify the source code (I take a copy of the matrix, instead of a reference) to get rid of the warning. But I'm wondering whether the warning itself is legitimate:

1. At execution time, everything seems to be fine.
2. I myself, do not see why the reference would be temporary.
3. I could read on the internet that this dangling reference warning produces many false positives.

What do you think?

[veprbl]

I think, the warning is a good one. In many ABIs your matrix is placed on stack and may get overwritten if you call something else before you use it.

(Haven't looked at the PR yet, this needs to be compilable on CI first)

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/2)

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (2/2)

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

[github-actions]

Capybara summary for PR 2177

• rec_dis_10x100_minQ2=0_craterlake_10x100
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=0_craterlake_18x275_MT
• rec_dis_18x275_minQ2=0_craterlake_18x275_ST_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275_ST_MT
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake

Last updated 2025-11-08T16:13-05:00 d1c963a

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

No Clang-Tidy warnings found so I assume my comments were addressed

[ybedfer]

Hello,
I don't know how to fix the detector benchmarks failure. I'm not even able to identify what the error is exactly. The only error message I could single out is the following:

Error in rule warmup_run:
    jobid: 4
    output: warmup/epic.edm4hep.root
    shell:

Which does not tell much...

[veprbl]

It makes no sense to hardcode these, just query a BitFieldElement from IDDescriptor, don't do your own bit operations.

[ybedfer]

I am not sure I agree here.
The hard-coding has the definite purpose of simplifying the source code. It does so by restricting the freedom of the user: the lesser the number of allowed combinations, the easier it is to navigate through all these cellIDs, to my mind.
I have in store (not in this PR) a piece of code where I check that these hard-coded bit fields are indeed implemented in the XML specification of the IDDescriptor.
In order to get rid of the hard-coding, I would have to introduce in the IDDescriptor a field for the 'p' strip, the 'n' strip, etc... for all of my five sub-volumes. I don't think it will make the source easier to understand. Here, on the contrary, the whole bit manipulation scheme is encapsulated in a block of seven definitions. The user who has to write an XML for its detector can refer to this concise and easily understandable block.

[veprbl]

Like you describe, this is very complicated, and I don't understand the approach. Also, the edge cases you describe don't help with putting confidence in this.

And you are right, this will require some provisions for backwards-compatibility. At very least we need to have new EICrecon work with older geometries (e.g. it could detect that "old" style detector is loaded and switch away from strip digitization). Can you share which branch of epic this can work with?

[ybedfer]

@veprbl

Like you describe, this is very complicated, and I don't understand the approach. Also, the edge cases you describe don't help with putting confidence in this.

The approach is simple: split the sensitive volume so as to have one sub-volume for 'p' strips and one for 'n' strips.
The implementation is complicated, because:

• I need a one and same detector structure for the RealData and for MC. For RD, I then need to have these sub-volumes at the center and thin. => More sub-volumes have to be introduced to collect the energy deposit. I cannot merely subdivide my sensitive volume into two.
• Then I need to coalesce the sub-hits. Otherwise I miss the time and amplitude correlation between 'p' and 'n', as is explained in the comment in the header of MPGDTrackerDigi.cc.
• Then I want to prevent sub-hits that are not traversing from being coalesced. Hence the edge issue: those edge hits cannot be associated to anything else taking place in another sub-volume of the sub-volume stack. They may be traced to something else taking place in a neighboring module, but then we're dealing with a completely different hit, not correlated in any way with the the first one. (The whole edge business, I wrote to be on the safe side. A priori, there should not be ambiguous cases where a particle exits though the edge and still re-enters into the sensitive volume of the same module. But one never knows for sure: looping particles?)

Bottom line: it's complicated, but it is working. (If someone else come up with a simpler working solution, he is welcome.)

And you are right, this will require some provisions for backwards-compatibility. At very least we need to have new EICrecon work with older geometries (e.g. it could detect that "old" style detector is loaded and switch away from strip digitization). Can you share which branch of epic this can work with?

• Backward compatibility? Basically, it's achieved with option -PMPGD:SiFactoryPattern.
• Yet, it is not possible with a unique XML.
• But, as I mention in a previous reply, I have in store a piece of code that is able to double-check that the XML supplied is a valid 5-subvolume one. If not, I throw an exception.

I am to have a PR for epic.

[ybedfer]

@veprbl

Can you share which branch of epic this can work with?

The branch is: "https://github.com/eic/epic/tree/Multi-SensitiveVolume-MPGD".
For MPGD Barrel:

• New "5SensVolumes" XML files are added. Previous ones are kept unchanged.
• The constructors can digest both. => Backward compatibility.