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 (now 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 (now included in the present PR).
• 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-27T14:06-05:00 7afe33a

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

[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.

I have committed a more modular version of the code. The complication involved in the construction of hits out of the elementary sensitive volumes is still there. But it's now moved to subprocesses, while the layout of the main process (that I am going to expand in a future commit, by introducing multi-hit clusters) is kept simple.

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?

I also made a move into that direction: MPGDTrackerDigi now checks that the segmentation of the MPGDs is appropriate and throws an exception if not, e.g. when a pixel-like segmentation.

[ybedfer]

Would anybody know how to fix the failing check? Error message is the following:

Run eic/trigger-gitlab-ci@v3
Run # Parse VARIABLES into multiple arguments
+ curl -X POST --fail-with-body -o response.json -F token=*** -F ref=master -F 'variables[GITHUB_REPOSITORY]=eic/EICrecon' -F 'variables[GITHUB_SHA]=df028e17ba490070b2847963b0c98a684a389c0b' -F 'variables[GITHUB_PR]=2177' -F 'variables[EICRECON_VERSION]="MultiSensitiveMPGD"' -F 'variables[PIPELINE_NAME]=eic/EICrecon: MPGDTrackerDigi: Multi-SensitiveVolume solution for the 2D-strip read…' https://eicweb.phy.anl.gov/api/v4/projects/290/trigger/pipeline
Unable to parse variable 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  1464  100   407  100  1057    347    901  0:00:01  0:00:01 --:--:--  1250
100  1464  100   407  100  1057    347    901  0:00:01  0:00:01 --:--:--  1250
curl: (22) The requested URL returned error: 422
+ RETCODE=22

[wdconinc]

Would anybody know how to fix the failing check? Error message is the following:

Run eic/trigger-gitlab-ci@v3
Run # Parse VARIABLES into multiple arguments
+ curl -X POST --fail-with-body -o response.json -F token=*** -F ref=master -F 'variables[GITHUB_REPOSITORY]=eic/EICrecon' -F 'variables[GITHUB_SHA]=df028e17ba490070b2847963b0c98a684a389c0b' -F 'variables[GITHUB_PR]=2177' -F 'variables[EICRECON_VERSION]="MultiSensitiveMPGD"' -F 'variables[PIPELINE_NAME]=eic/EICrecon: MPGDTrackerDigi: Multi-SensitiveVolume solution for the 2D-strip read…' https://eicweb.phy.anl.gov/api/v4/projects/290/trigger/pipeline
Unable to parse variable 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  1464  100   407  100  1057    347    901  0:00:01  0:00:01 --:--:--  1250
100  1464  100   407  100  1057    347    901  0:00:01  0:00:01 --:--:--  1250
curl: (22) The requested URL returned error: 422
+ RETCODE=22

This container config issue has since been fixed. Successfully retriggered at https://github.com/eic/EICrecon/actions/runs/19600651386/job/56163648693.

[ybedfer]

Hello,
Is there any chance that the Merging is approved any time soon? What do I need to do to unblock the situation?

My plan is to next have:

• A commit of epic branch: "https://github.com/eic/epic/tree/Multi-SensitiveVolume-MPGD".
  What's missing there is a scheme to ensure backward compatibility. I have been thinking about the following:

  • A set of constants defined in the XMLs, e.g. InnerBarrel2DStrip/InnerBarrel2DStrip.
  • Access these constants in the MPGD plugin detectors/MPGD/MPGD.cc. There is a piece of code in the FEMC plugin doing that. But it does not work in the MPGD context, unfortunately.
  • Determine which of SiliconTrackerDigi or MPGDtrackerDigi is used, based on these constants.

  Also, I have to fix the following problem: when I subdivide the sensitive volume (of typically 3 mm of depth) into subVolumes (w/ a narrower depth of 1.5 mm), I get fewer SimHits from ddsim. I can work around that by lowering the EnergyDepositMinimumCut (from 1 keV to 0.5 keV) in the steering options of ddsim. But I don't know how to implement that directly from the XML.

• Then, a commit of EICrecon implementing the production of clusters of RawHits.

• Then I would be ready to do such things as determining accurately the rates in the MPGDs and evaluate accurately the impact of the MPGs with 2DStrip readout, on tracking (I recall that MPGDs cannot be read out with pixels: 2DStrip is not optional).

To keep on fulfilling this plan, I need the approval of the present PR.

[veprbl]

Hello, Is there any chance that the Merging is approved any time soon? What do I need to do to unblock the situation?

This is a very large PR and my backlog is significant. I'll try to look. If you have anyone from tracking group check your changes that would be a good help. All in all, we may want to schedule a meeting to discuss this. Would you be available for reco meeting slot 11AM EST Monday Dec 1st?

My plan is to next have:

• A commit of epic branch: "https://github.com/eic/epic/tree/Multi-SensitiveVolume-MPGD".
  What's missing there is a scheme to ensure backward compatibility. I have been thinking about the following:

  • A set of constants defined in the XMLs, e.g. InnerBarrel2DStrip/InnerBarrel2DStrip.

Please use a consistent prefix MPGDInnerBarrel_

• Access these constants in the MPGD plugin detectors/MPGD/MPGD.cc. There is a piece of code in the FEMC plugin doing that. But it does not work in the MPGD context, unfortunately.

This is fine.

• Determine which of SiliconTrackerDigi or MPGDtrackerDigi is used, based on these constants.

Also, I have to fix the following problem: when I subdivide the sensitive volume (of typically 3 mm of depth) into subVolumes (w/ a narrower depth of 1.5 mm), I get fewer SimHits from ddsim. I can work around that by lowering the EnergyDepositMinimumCut (from 1 keV to 0.5 keV) in the steering options of ddsim. But I don't know how to implement that directly from the XML.

The energy cut should be zero in npsim, which is the recommended tool that is used for the productions.

[bschmookler]

Hi @ybedfer @veprbl. I'll have some time to look at this PR on Wednesday or Thursday this week.

[ybedfer]

This is a very large PR and my backlog is significant. I'll try to look. If you have anyone from tracking group check your changes that would be a good help. All in all, we may want to schedule a meeting to discuss this. Would you be available for reco meeting slot 11AM EST Monday Dec 1st?

Yes.

[ybedfer]

Hello,
I committed a new version of the MPGD plugin which activates MPGDTrackerDigi based on an XML constant.

I am doing this in order to speed up the overall PR procedure (which already includes an epic PR and yet another EICrecon PR).

The new feature is to take advantage of a reshuffling of the MPGDs in epic (XML and detector builder), which I have committed to my "https://github.com/eic/epic/tree/Multi-SensitiveVolume-MPGD" branch to ease backward compatibility:

• Each MPG comes in two flavors: pixel and 2DStrip, implemented in two distinct XMLs: "_pixel.xml"/"_2DStrip.xml" (still processed by a one and same detector builder).
• A cmake command line option allows to install one or the other.

[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