The compiler upgrade is from gcc 9.3.0 with -std=c++17 to gcc 13.1.0 with -std=c++20. This is captured in the e20 and e28 qualifiers on the ups products.
The before and after commits are:
Offline:
Before: SHA ef911e8 PR 1081 uninitialized variable changes and a bug fix for e28 compatibility
After: SHA 9b5049c Pr 1084 envset change for e28 compiler upgrade
Production: Same commit for both
SHA 29d888f3 PR 265 ComboHitCollection Migration
To reproduce:
- Start from Production/Validation/nightly/ceMix_00.fcl
- Add the line: physics.filters.MuStopPileupMixer.mu2e.MaxEventsToSkip : 0
- You may also want to change the paths to the input files from xrootd to NFS.
Step 2 is needed to work around another issue that masks this one.
Run 100 events and valCompare the output. There is a trivial change in the histogram but I looked more closely by running the following code on each of the art output files:
art::ProductToken<CaloClusterCollection> _caloClustersToken("CaloClusterFast");
auto const& caloClusters = event.getProduct(_caloClustersToken);
int i{0};
for ( auto const& cl : caloClusters ) {
cout << " Cluster: "
<< event.id().event() << " "
<< cl.time() << " "
<< i++ << " : "
<< cl.energyDep() << " "
<< cl.cog3Vector().perp()
<< endl;
} // end loop over caloClusters
A diff of the two log files gives:
---
48c48
< Cluster: 15 413.617 0 : 27.5625 440.925
---
> Cluster: 15 413.617 0 : 34.9609 446.191
98c98
---
116,119c116,119
< Cluster: 24 533.11 10 : 18.2656 628.027
< Cluster: 24 533.11 11 : 24.1484 413.027
< Cluster: 24 618.11 12 : 12.5859 609.006
< Cluster: 24 618.11 13 : 37.0781 396.227
---
> Cluster: 24 533.11 10 : 24.1484 413.027
> Cluster: 24 533.11 11 : 18.2656 628.027
> Cluster: 24 618.11 12 : 37.0781 396.227
> Cluster: 24 618.11 13 : 12.5859 609.006
186,187c186,187
< Cluster: 35 475.758 8 : 16.8438 417.278
< Cluster: 35 475.758 9 : 12.2734 560.729
---
> Cluster: 35 475.758 8 : 12.2734 560.729
> Cluster: 35 475.758 9 : 16.8438 417.278
There are two observations. First, in event 15 it finds two very different clusters. This happens again in event 37. Second, there are lots of cases of finding the same clusters but in different orders.
I am mostly concerned with the first issue - finding very different clusters. I don't know if the change in sort order is important or if it's an accident of the evolution of sort algorithms in std:: .
The compiler upgrade is from gcc 9.3.0 with -std=c++17 to gcc 13.1.0 with -std=c++20. This is captured in the e20 and e28 qualifiers on the ups products.
The before and after commits are:
Offline:
Before: SHA ef911e8 PR 1081 uninitialized variable changes and a bug fix for e28 compatibility
After: SHA 9b5049c Pr 1084 envset change for e28 compiler upgrade
Production: Same commit for both
SHA 29d888f3 PR 265 ComboHitCollection Migration
To reproduce:
Step 2 is needed to work around another issue that masks this one.
Run 100 events and valCompare the output. There is a trivial change in the histogram but I looked more closely by running the following code on each of the art output files:
A diff of the two log files gives:
There are two observations. First, in event 15 it finds two very different clusters. This happens again in event 37. Second, there are lots of cases of finding the same clusters but in different orders.
I am mostly concerned with the first issue - finding very different clusters. I don't know if the change in sort order is important or if it's an accident of the evolution of sort algorithms in std:: .