TS+light pipes+Trackers Geometry for ESA (ldmx_reduced_v3)

[Layan-Sarayra]

I am updating ldmx-sw, here are the details.

What are the issues that this addresses?

This partially resolves #iss1880, it's the TS+light pipes+Tracker subsystems geometry for ESA slice test.

Check List

• I successfully compiled ldmx-sw with my developments.
• I read, understood and follow the coding rules.
• I ran my developments and the following shows that they are successful.

I duplicated ldmx-reduced-v2 and called it ldmx-reduced-v3, and made changes to the following files:
constants.gdml
detector.gdml
materials.gdml
target.gdml
trig_scint.gdml
ldmx-sw/.github/validation_samples/reduced_ldmx/config.py

I built the geometry for ldmx-reduced-v3 based on the CAD layouts Majd Ghrear designed (I annotated in red, but all the designs are Majd's work!)

Key changes between ldmx-reduced-v2 and ldmx-reduced-v3:

1. Positioning: Things are still with respect to target (target=0mm)
   • TS1 : −381.0 mm
   • TS2 : −304.8 mm (TS2 is 76.2 mm downstream of TS1)
   • Tracker 1 (tagger): −240.5 mm (64.3 mm downstream of TS2)
   • Tracker 2 (recoil): −140.5 mm (100 mm downstream of tracker 1)
   • TS3 : −76.2 mm (64.3 mm downstream of tracker 2)
   • Target : 0 mm (76.2 mm downstream of TS3)
   • Increased the mother envelope area in target.gdml to fit target and TS pad 3

2. Trigger Scintillator (Pads 1 and 2, and same pattern for Pad 3 in target.gdml):
   • Each pad now has: 12 bars per layer × 2 layers = 24 bars
   • Bars are 3 mm (y) × 2 mm (z)
   • Neighboring bars in y: 0.15 mm gap.
   • Layers are shifted by 1.55 mm in y.
   • Z: layer centers are 4 mm apart (2 mm thickness + 2 mm gap).
   • 0.15 mm Y-gap, 1.55 mm Y-shift, 2 mm Z-gap → 4 mm center separation

3. Added light pipes:
   • Material defined/added to materials.gdml
   • 12 bars per layer x 2 layers = 24 bars
   • Bars are 2 mm x 2 mm
   • “glued” to TS bars (in Pads 1, 2, and 3)

4. Replaced ldmx-reduced-v2 to ldmx-reduced-v3 in .github/validation_samples/reduced_ldmx/config.py

I ran a geometry check and it passed. Then ran a simulation of 1e+6 events and it processed all events successfully. Here are the energy deposition plots for TS Pad 1, 2, and 3 with light guides, target, tagger and recoil trackers.

I have a few comments:

• Light pipes for now are passive. Ultimately, we’ll need to define how to handle energy deposited in them.
• Patill and I are working on replacing the tungsten with LYSO and adding light pipes to it too.
• We aren’t seeing anything in the tagger tracker because it’s a copy of ldmx-reduced-v2, and for it the sensors were removed entirely. Please advise me on what to do with the trackers.
• I commented out the Ecal and Hcal in detector.gdml, but it’s fine because their ESA geometry is different from ldmx-reduced-v2.
• Is there a way to change where the beam starts?

[cjbarton151]

Hey Layan - thanks for making the PR!

To get everyone on the same page, I would recommend to git rebase trunk.

The heap-buffer-overflow failure of the address sanitizer validation test should be fixed soon, so don't worry about that one.

For the errors in the other validation tests of the type

[ fire ] 1 fatal: [GeometryException] : Unable to create EcalGeometry

When making a new version of ldmx-sw geometry that includes ECal/HCal, it seems to be necessary to update these files:
DetDescr/python/EcalGeometry.py
DetDescr/python/HcalGeometry.py
and I think
Ecal/python/digi.py

Basically, everywhere you see ldmx-reduced-v2 mentioned in these files, copy those classes and make an ldmx-reduced-v3 version, or update the arrays to also include ldmx-reduced-v3

I was able to get past the ECal and HCal definitions locally by doing this, although now I'm seeing other problems with the DQM... But one problem at a time, right? :^)

[cjbarton151]

Hey Layan - would you mind rebasing to trunk, to see if that fixes the issue with the validation checks? It should fix the clang-tools check for sure, not certain about the compilation error.

[cjbarton151]

Thanks for continuing to work on this! I believe we're getting close to finishing...

From the reduced_ldmx validation test we have:
[ fire ] 1 fatal: [ProductNotFound] : No product found for name 'TriggerPadTracks'

So it looks like one or more TS pads aren't being created.

I downloaded this PR and reverted trig_scint.gdml to the ldmx-reduced-v2 version, and also reverted this line in detector.gdml:
<variable name="trig_scint_pos_z" value="-344.0255*mm" />
to
<variable name="trig_scint_pos_z" value="tagger_pos_z-trig_scint_area_envelope_z/2 -tagger_envelope_dz/2- clearance - 200" />

When I made these 2 changes, I was able to run the validation test locally with no errors.

One thing I find interesting is that I didn't revert target.gdml, so v3 of this file is working just fine.

I would recommend double-checking the new trig_scint.gdml and possibly this trig_scint_pos_z variable to see if perhaps the new TSpads are still outside of the envelope (or the world) to see if we can get the validation test working. Best of luck!

[Layan-Sarayra]

I'll work on fixing trig_scint.gdml. I'm relieved to know that target is looking good! I have some plots of e-dep in LYSO once validation tests run successfully I'll upload a few. Thanks CJ!

[tvami]

hi @Layan-Sarayra a few things should be cleaned up in this branch, for example none of the v15 geometry changes should be included. Then the ldmx-reduced-v3 is not introduced and includes the ECAL changes, so your files dont need to touch anything ECAL related. I see you also included HCAL related changes, I'd suggest to have that in another PR and concentrate on the TS + tracker here

[bryngemark]

I agree with @tvami that the v15 stuff should be taken out and this PR should just be what the issue title says: TS+lightpipes+tracker in the reduced geometry. Do you know how to undo changes you added in a branch from your PR?

I also think that if you're using three TS loops in this geometry in place of @cjbarton151 's assembly technique, so be it. As long as we have this new way of doing it going forward, I'm happy.

Besides these two things, is there anything else holding you up?

[tvami]

A lot is happening in this PR (thanks for your work!), so I think I'll have to review this again, but for now these are my comments. My biggest confusion is to have any detector element at negative z values. I think everything in the slice test is supposed to be positive z.

[Layan-Sarayra]

Thank you all for the feedback, it’s very helpful.

@bryngemark I reverted the ldmx-det-v15-8gev changes. I hadn’t noticed it still included light pipes related updates, thanks for catching that. At this point, the only remaining issue on my side is TS pad 3. Pads 1 and 2 are working as expected, as well as the LYSO+light pipes module (my latest major update), but TS pad 3 is still showing no events. I’m actively debugging that and will have an update soon.




(small simulation of 1k events, 8 GeV)

@tvami thanks for reviewing! I applied most of your suggestions and pushed an updated version. I will also keep this PR TS + LYSO specific and open a separate PR for the trackers.

On the negative z-values: I kept the convention of placing the “target” at z = 0 (as in ldmx-reduced-v2, and I believe consistent with other detector versions). I replaced the tungsten target with the LYSO + light pipes module but intentionally kept the file name as is and used that as a reference point. In the CAD model of this subsystem the beam encounters (in order): TS pad 1 → TS pad 2 → the two trackers → TS pad 3 → LYSO. With LYSO anchored at z = 0, everything upstream naturally ends up at negative z. Here are a couple of photos from the installation at ESA.

[tvami]

Thanks @Layan-Sarayra for the update! Indeed my confusion came from the fact that I thought LYSO is in the front (the first detector downstream the beampipe), thanks for attaching the pictures / CAD models and clarifying that!

[tvami]

The CI fails with

[ fire ] 1 fatal: [ProductNotFound] : No product found for name 'TriggerPadTracks'
    at /home/runner/work/ldmx-sw/ldmx-sw/Framework/include/Framework/Event.h:303 in getObject
  [ fire ] 1 debug:     0 std::vector<ldmx::TrigScintTrack, std::allocator<ldmx::TrigScintTrack> > const& framework::Event::getObject<std::vector<ldmx::TrigScintTrack, std::allocator<ldmx::TrigScintTrack> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const + 12080 
      1 dqm::TrigScintTrackDQM::analyze(framework::Event const&) + 70 
      2 framework::Process::process(int, int, framework::Event&) const + 174 
      3 framework::Process::run() + 10860 
      4 fire(+0x5165) [0x5563da910165]
      5 /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7fad9cff01ca]

I'm not sure if we were expecting the TS tracking to work yet with this geom?

[tvami]

TS tracking still not working

[ TrigScintDigiPad3 ] 1 debug: Looping over hits in trigScintDigisPad3
  [ fire ] 1 fatal: [ProductNotFound] : No product found for name 'TriggerPadTracks'
    at /home/runner/work/ldmx-sw/ldmx-sw/Framework/include/Framework/Event.h:303 in getObject
  [ fire ] 1 debug:     0 std::vector<ldmx::TrigScintTrack, std::allocator<ldmx::TrigScintTrack> > const& framework::Event::getObject<std::vector<ldmx::TrigScintTrack, std::allocator<ldmx::TrigScintTrack> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const + 12080 
      1 dqm::TrigScintTrackDQM::analyze(framework::Event const&) + 70 
      2 framework::Process::process(int, int, framework::Event&) const + 174 
      3 framework::Process::run() + 10860 
      4 fire(+0x5165) [0x5565e10f4165]
      5 /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7f35162521ca]

[bryngemark]

regarding TS tracking failing. i see a few possible causes.

1. no hits in Pad3 yet? then tracking will fail. we need clusters in all three pads.
2. if there are hits in all pads now, check the timing of the simhits. we use a time cut on what hits to include in clusters, in order to avoid including hits from backscatter etc in tracking. with this different geometry, the expected time of arrival to the pads might be a little different. the time cut is a configurable parameter for clustering at each pad. (if this is too strict, all hits are removed, meaning no clusters in one or all pads, meaning no tracks.)