refactor: Remove Sequencer dataflow override

[paulgessinger]

This option does more harm than it does good, so I propose we remove it altogether.

[asalzburger]

This option does more harm than it does good, so I propose we remove it altogether.

You want to always check the dataflow then?

Both @benjaminhuth and I had problems with the check, i.e. we then need to get to the bottom of it why this could potentially fail.

[paulgessinger]

@asalzburger Exactly. If you can reproduce it, it would be great to investigate why it fails.
You can also hack it out for a quick test, but I think having a flag in the main branch is dangerous.

[andiwand]

I also believe the check is fine and it is a good protection mechanism against inconsistent data types on the whiteboard of our Examples Framework. If there are problems with that mechanism it is highly likely that it fails due to inconsistent compilation units which might be cause by build caches like ccache or dirty build folders. For more details see the discussion here https://mattermost.web.cern.ch/acts/pl/teonnaeyzjf1xqzgcz9nuyobzy

I would generally argue against these kinds of workarounds against protection mechanisms as this looks like we are hacking them and distrusting them on purpose. If people experience problems with it, it is most likely a symptom of a deeper issue and the actual issue should be treated instead of the symptom. No one will stop one from hacking it locally, this is simply one line change to "make it work" but I would urge to keep the main repo clean of it.

[benjaminhuth]

So I agree that if the check fails, this is a sign that something in the build that is used is wrong, so removing the option alltogether is also fine...

But yeah, as @paulgessinger said, I see myself already hacking this in cases this happens and rebuild of the whole acts+dependencies is not an option immediatly...

[paulgessinger]

@benjaminhuth If we understand why it happens we could try to identify which parts need to be rebuild. The mismatch that @asalzburger reported this morning, flat_map, is a header-only part of boost. That would indicate to me that it's not a dependency issue, but a build consistency issue, possibly ccache.

It's possible that the check is faulty, in which case it should be improved rather than just ignored. I can't reproduce this issue at this moment, so I can't debug it myself, which is why I'd love if you or @asalzburger could help debugging this.

[benjaminhuth]

@asalzburger did you also used ccache when that occurred? The thing that we have in common I think that it also only happened to me when I use clang as compiler...

So when it happens the next time I will try again to dig into this, but I really think this is due to some build incompatibilities and not solvable from the repository side.

[github-actions]

📊: Physics performance monitoring for acdb2db

Full contents

physmon summary

• ✅ Particles fatras
• ✅ Particles geant4
• ✅ Particles ttbar
• ✅ Vertices ttbar
• ✅ Truth tracking (KF)
• ✅ Truth tracking (GSF)
• ✅ Truth tracking (GX2F)
• ✅ CKF | trackfinding | single muon | truth smeared seeding
• ✅ Track Summary CKF | trackfinding | single muon | truth smeared seeding
• ✅ Seeding trackfinding | single muon | truth estimated seeding
• ✅ CKF | trackfinding | single muon | truth estimated seeding
• ✅ Track Summary CKF | trackfinding | single muon | truth estimated seeding
• ✅ Seeding trackfinding | single muon | default seeding
• ✅ CKF | trackfinding | single muon | default seeding
• ✅ Track Summary CKF | trackfinding | single muon | default seeding
• ✅ Seeding trackfinding | single muon | orthogonal seeding
• ✅ CKF | trackfinding | single muon | orthogonal seeding
• ✅ Track Summary CKF | trackfinding | single muon | orthogonal seeding
• ✅ Seeding trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Track Summary CKF | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Ambisolver | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ IVF notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF gauss notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF grid time | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Seeding trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF | trackfinding | ttbar with 200 pileup | default seeding
• ✅ Track Summary CKF | trackfinding | ttbar with 200 pileup | default seeding
• ✅ Ambisolver | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding

[asalzburger]

Let's merge this one then.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[acts-project-service]

✅ Athena integration test results [9ee3a10]

✅ All tests successful

status	job	report
🟢	report_pull_request
🟢	run_art_test: test_data18_13TeV_1000evt
🟢	run_art_test: test_ttbarPU40_reco
🟢	test_ActsDumpGeometryIdentifiers
🟢	test_ActsCheckObjectCountsCachedWorkflow
🟢	test_ActsCheckObjectCountsWorkflow
🟢	test_ActsEFTrackFit
🟢	test_ActsPersistifySeeds
🟢	test_ActsBenchmarkWithSpot
🟢	test_ActsAnalogueClustering
🟢	test_ActsWorkflowHeavyIons
🟢	test_ActsWorkflowFastTracking
🟢	test_ActsWorkflowCached
🟢	test_ActsWorkflow
🟢	test_ActsValidateAmbiguityResolution
🟢	test_ActsValidateResolvedTracks
🟢	test_ActsValidateTracks
🟢	test_ActsValidateActsCoreSpacePoints
🟢	test_ActsValidateActsSpacePoints
🟢	test_ActsValidateSeeds
🟢	test_ActsValidateOrthogonalSeeds
🟢	test_ActsValidateClusters
🟢	test_ActsPersistifyEDM
🟢	test_ActsGSFRefitting
🟢	test_ActsKfRefitting
🟢	test_ActsExtrapolationAlgTest
🟢	test_ActsITkTest
🟢	run_workflow_tests_run4_mc
🟢	run_workflow_tests_run2_mc
🟢	run_workflow_tests_run2_data
🟢	run_workflow_tests_run3_mc
🟢	run_workflow_tests_run3_data
🟢	run_unit_tests