chore: root-6.38.04

[wdconinc]

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

This PR updates ROOT to 6.38.04 (before we make a jump to 6.40). Diff at root-project/root@v6-38-00...v6-38-04. Release notes at https://github.com/root-project/root/releases/tag/v6-38-04 and https://github.com/root-project/root/releases/tag/v6-38-02.

Needs:

• root: patch to ensure GIL is held during CPython API call eic-spack#943

What is the urgency of this PR?

• High (please describe reason below)
• Medium
• Low

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue: version update)
• Optimization (issue #__)
• Updated documentation
• other: __

Please check if any of the following apply

• This PR introduces breaking changes. Please describe changes users need to make below.
• This PR changes default behavior. Please describe changes below.
• AI was used in preparing this PR. Please describe usage below.

[Copilot]

Pull request overview

Updates the Spack environment’s ROOT requirement to 6.38.04, aligning the container software stack with the desired ROOT patch release prior to a later move to 6.40.

Changes:

• Bump ROOT version requirement from @6.38.00 to @6.38.04 in spack-environment/packages.yaml.

[github-actions]

Capybara summary for PR 297

• rec_dis_10x100_minQ2=1000_epic_craterlake (new artifact) (ref artifact)
• rec_dis_10x100_minQ2=1_epic_craterlake (new artifact) (ref artifact)
• rec_dis_18x275_minQ2=1000_epic_craterlake (new artifact) (ref artifact)
• rec_dis_18x275_minQ2=1_epic_craterlake (new artifact) (ref artifact)
• rec_dis_5x41_minQ2=1_epic_craterlake (new artifact) (ref artifact)
• rec_e_1GeV_20GeV_epic_craterlake (new artifact) (ref artifact)
• rec_pi_1GeV_20GeV_epic_craterlake (new artifact) (ref artifact)
• sim_dis_10x100_minQ2=1000_epic_craterlake (new artifact) (ref artifact)
• sim_dis_10x100_minQ2=1_epic_craterlake (new artifact) (ref artifact)
• sim_dis_18x275_minQ2=1000_epic_craterlake (new artifact) (ref artifact)
• sim_dis_18x275_minQ2=1_epic_craterlake (new artifact) (ref artifact)
• sim_dis_5x41_minQ2=1_epic_craterlake (new artifact) (ref artifact)
• sim_e_1GeV_20GeV_epic_craterlake (new artifact) (ref artifact)
• sim_pi_1GeV_20GeV_epic_craterlake (new artifact) (ref artifact)
  ^{_{Last updated 2026-06-10T02:55-04:00 cde4d1c}}

[veprbl]

Somehow we get much fewer hits in this one. Let's re-run CI.

[wdconinc]

Where do you see that? I see stat diffs but no significant diffs.

[veprbl]

I check for Q2>1000, where it's much more pronounced.

[ruse-traveler]

Looks good! Most of the diffs look reasonable to me: time stamp has changed, which -- I think -- would propagate to the OM hits' time being different (where most of the other diffs are).

But I was surprised by the the raw index for the sim-raw hit OM associations changing slightly (though sim index is unchanged), like here... Granted, the diffs are within statistics...

[wdconinc]

But I was surprised by the the raw index for the sim-raw hit OM associations changing slightly (though sim index is unchanged), like here... Granted, the diffs are within statistics...

I dug into this, and there is already an ordering mismatch between the hits in the simulation output... I am still investigating why, but it is unlikely that the ROOT upgrade introduced something to cause the reordering, and I am more suspicious of something somewhere (Geant4, DD4hep, podio) using a map keyed on pointer.

[wdconinc]

The underlying cause here is that the ForwardOffMTracker is really four detectors that each write to ForwardOffMTrackerHits. That means there's one SensitiveDetector, and four TGeoVolumes. This is stored in a std::map<SensitiveDetector, std::set<const TGeoVolume*>> in https://github.com/AIDASoft/DD4hep/blob/7693cca27dd057bb22414c86b95fedbab49f6ae5/DDG4/include/DDG4/Geant4GeometryInfo.h#L135, and then iterated over in https://github.com/AIDASoft/DD4hep/blob/7693cca27dd057bb22414c86b95fedbab49f6ae5/DDG4/plugins/Geant4DetectorSensitivesConstruction.cpp#L87-L101. This makes the ordering of the four hit collections dependent on the pointer value, so we have no determinism on which station is stored when.

[ruse-traveler]

The underlying cause here is that the ForwardOffMTracker is really four detectors that each write to ForwardOffMTrackerHits. That means there's one SensitiveDetector, and four TGeoVolumes. This is stored in a std::map<SensitiveDetector, std::set<const TGeoVolume*>> in https://github.com/AIDASoft/DD4hep/blob/7693cca27dd057bb22414c86b95fedbab49f6ae5/DDG4/include/DDG4/Geant4GeometryInfo.h#L135, and then iterated over in https://github.com/AIDASoft/DD4hep/blob/7693cca27dd057bb22414c86b95fedbab49f6ae5/DDG4/plugins/Geant4DetectorSensitivesConstruction.cpp#L87-L101. This makes the ordering of the four hit collections dependent on the pointer value, so we have no determinism on which station is stored when.

Ahhhh I see! Thank you for looking into that! In that case, this PR is good-to-go!