Ambiguity Resolution: remove duplicate measurements for each track

[SylvainJoube]

This PR ensures that the greedy solver deals with tracks that have unique measurement IDs, removing duplicates, if any.

I was able to replicate the issue with the geant4_ttbar_mu20 data provided by Attila on PR Data V7, main branch (2024.05.03.) #561 and the command line written at the beginning of issue Ambiguity Resolution Errors on ODD ttbar Simulation (2024.05.04.) #564.

It turns out that I did not anticipate that a track could be made of the same measurement_id several times. This happened twice on the generated data from geant4_ttbar_mu20: for tracks 1176 and 720, that’s why the greedy solver was showing an error. The same “error” should exist on ACTS too, since the Greedy Solver code remains mostly unchanged. I have just taken a look at file Core/include/Acts/AmbiguityResolution/GreedyAmbiguityResolution.ipp from ACTS.

For example, in issue Ambiguity Resolution Errors on ODD ttbar Simulation (2024.05.04.) #564, the track of index 720 has measurements: 2878 4167 5155 15837 15837, with 15837 twice.

I could have changed the std::vector<std::size_t> measurements into a std::set<std::size_t> but I'm not sure of the performance implications of such a change, and I'm a little short on time, so this is a quick fix!

[krasznaa]

It's excellent that you understood where the issues / error messages come from.

But I'm not convinced that this should be "fixed" in the ambiguity resolution algorithm. 🤔 Making the algorithm robust against such input is absolutely good. But the track finding should really not be attaching the same measurement multiple times to the same track.

@beomki-yeo, how would this happen? Looping tracks? 😕

For now, this sort of a check seems good. (Just making the thing into a warning.) But eventually, once the track finding is not expected to produce such tracks, I would demote these checks into assertions. I.e. something like:

assert([&]() {
    // code that decides whether there are measurement duplicates on a track
    }() == false);

(I've been thinking recently about adding a few more of such assertions into our algorithms...)

[SylvainJoube]

Thank you for your feedback Attila!

I’ve modified the code to clearly display a single warning message per track with duplicate measurements. It can handle multiple duplicate measurements without being too verbose. The output now displays:

WARNING: @greedy_ambiguity_resolution_algorithm: Track 1171 has duplicated measurement(s): 15195 (2 times). Measurement list: 3291 3475 4518 7396 8617 9632 9625 10484 15195 15195 15269 15268

WARNING: @greedy_ambiguity_resolution_algorithm: Track 720 has duplicated measurement(s): 15837 (2 times). Measurement list: 2878 4167 5155 15837 15837

[krasznaa]

Okay, let's go for this. 👍

[SylvainJoube]

@krasznaa @beomki-yeo ping 🦊

[krasznaa]

Ahh, shoot... I thought with the approval in place you would be able to merge it yourself. Completely forgot about this... 😦

[SylvainJoube]

Thank you Attila! No worries, I was just afraid that, as time went by, I would have complicated merge conflicts :’)

[krasznaa]

Unfortunately we have a lot of traffic on the repository today, so my auto-merge will most likely not work anymore. But let's see... Since the CI takes a long time to run right now, we might as well wait for it to finish, and only rebase the PR if really needed.

[SylvainJoube]

Okay, we'll wait then! The CI Bridge says Pipeline refused though, is it an issue or should we wait?

[beomki-yeo]

I dont know how it would happen. But as @krasznaa mentioned, this is not something to be fixed from ambiguity solver. At least, this kind of things should be documented somewhere cleary (e.g. issues)

@SylvainJoube Does this issue cause a serious problem in the final result? Otherwise, I would suggest documenting this in the issue category instead of fixing it in the ambiguity solver. Then someone will be able to try to handle the issue by fiximg the CKF or whatever.

[beomki-yeo]

The multiple module id should be understood better rather than fixing it in the ambiguity solver. For example, I would try to increase the configurarion value of minimal distance to reach the next surface in the finding_config.

[beomki-yeo]

I don't get why @krasznaa merged this PR after I requested the change. Duplicate ID is not even a bug in case of a looping track.

@SylvainJoube I want to hear your opinion on this. Does this PR filter tracks which have the "sequential" duicate ID or just filter tracks with duplicate IDs? We should not kill the tracks that have duplicate IDs because of a loop. (Even though the loop is not supposed to happen due to the limitation of detray)

[krasznaa]

I was curious when the question would come.

This was because of auto-merge. You made your comment Beomki, but didn't de-activate the auto-merge that was active on the PR. So when the CI finally finished, and nobody else merged another PR to prevent this from getting merged (as happened once earlier that day), it finally went in.

So now we know that when there is one approval and one change request on a PR, GitHub considers the PR approved. 🤔

It's a bit unfortunate indeed, but I personally didn't consider this PR too hurtful. If you check the discussion on it, I agree with you that the ambiguity resolution is not the place to sort this issue out. At the same time, this looked like an okay intermediate relief for #564.

So now, it's time to start looking for a real fix. 😉

[beomki-yeo]

I didn't know that the auto merge was activated. The PR itself is not very hurtful but I think we don't have to rush in merging PRs.

[krasznaa]

This was an unfortunate series of events. But "rushing" is a strange way to describe it. I approved this PR weeks ago. It was not something brand new.

[beomki-yeo]

Fine. Didn't even realize that i was pinged that long time ago - I was too busy with other affairs before the vacation.

Still, this duplicate ID problem needs to posted in the issue rather being left behind and forgotten eventually.