tracking: use Seeded tracks by default, rename previous default to TruthSeeded

[veprbl]

Briefly, what does this PR introduce?

As we agreed during the collaboration meeting, the real seeding workflow is mature and should become the default. This changes Seeded collections to not include that prefix, and prefixless collections are moved to TruthSeeding (name is long but not supposed to be used by general users). As a side effect, Jet finding and ReconstructedParticles and DRICH IRT-based PID will use real seeding.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No

Does this PR change default behavior?

Yes

[github-actions]

Capybara summary for PR 1605

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake
• rec_dis_5x41_minQ2=0_craterlake
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-09-07T19:47-04:00 abf1263}}

[sonarqubecloud]

Quality Gate failed

Failed conditions
39.9% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud

[wdconinc]

Changes make sense. I did not verify that this is the complete set of changes required. I assume you've grepped for other instances.

[michael-pitt]

Hi @veprbl ,

I'm not sure if I need to open an issue or if I can report it here. It seems that this RP also impacted the reconstruction of one of the far-forward sub-systems - the B0 Tracker. In the past we were using the ReconstructedChargedParticles container to get the B0 tracks. Since this RP, the B0 tracks moved to ReconstructedTruthSeededChargedParticles container. This might be OK since the b0 tracks are also using truth seeding, but I see that this container is called from src/detectors/DRICH/DRICH.cc#L211, which is not related to Far-Forward detectors. It wasn't easy to find out what had happened in this case.

I'm also motived some naming mismatch in src/global/tracking/tracking.cc:
L162 CentralCKFTrajectories -> CentralCKFActsTrajectoriesUnfiltered
L95 CentralCKFTruthSeededTrajectories->CentralCKFTruthSeededActsTrajectoriesUnfiltered

Will you confirm that the B0 tracks should be retrieved from ReconstructedTruthSeededChargedParticles container?

Thanks,
Michael

[veprbl]

I'm not sure if I need to open an issue or if I can report it here. It seems that this RP also impacted the reconstruction of one of the far-forward sub-systems - the B0 Tracker. In the past we were using the ReconstructedChargedParticles container to get the B0 tracks. Since this RP, the B0 tracks moved to ReconstructedTruthSeededChargedParticles container. This might be OK since the b0 tracks are also using truth seeding, but I see that this container is called from src/detectors/DRICH/DRICH.cc#L211, which is not related to Far-Forward detectors. It wasn't easy to find out what had happened in this case.

Will you confirm that the B0 tracks should be retrieved from ReconstructedTruthSeededChargedParticles container?

Two things here: One is that realistic seeding does not work for B0 tracking. We need to have it implemented. Until we do that, I think it's for the best that we are reminded that truth seeding is being used by having to access the ReconstructedTruthSeededChargedParticles. Truth seeding can produce quite misleading performances. Another thing is about data processing for ReconstructedParticles passing though PID factories, that is needed to provide PID LUTs. The reconstructed particles are not just about tracking, this is a holistic object, even more detectors will be used in the future.

I'm also motived some naming mismatch in src/global/tracking/tracking.cc: L162 CentralCKFTrajectories -> CentralCKFActsTrajectoriesUnfiltered L95 CentralCKFTruthSeededTrajectories->CentralCKFTruthSeededActsTrajectoriesUnfiltered

This refers to the two previous PRs: #1470 #1383
The CentralCKF*Acts* tags are Acts structures that are not PODIO and can't be e.g. directly written to an edm4eic.root file. We employ conversion from Acts to PODIO for now, but in the future the goal is to have algorithms to exchange PODIO structures only.

[michael-pitt]

OK, Thanks! (adding @ajentsch in case someone in FF group will have a similar question),

Indeed, I see that the central tracks are included in both ReconstructedTruthSeededChargedParticles and ReconstructedChargedParticles while B0 tracks are only in the ReconstructedTruthSeededChargedParticles container.

So, I will do the following:
Central tracks retrieved from ReconstructedChargedParticles
B0 tracks are retrieved from ReconstructedTruthSeededChargedParticles after applying an eta cut of 4.2 (trk_eta>4.2 in the hadron beam coordinate system).

[simonge]

Other than for simplicity is there a reason the B0 tracks are mixed into the same raw hit collection as the central tracker? Would it not be more useful to keep them separate until they are needed(?) by the vertex finder for timing. The same acts algorithms would be used with the same configuration, or something specifically tuned to the B0, without attempting to use B0 hits in central detector tracks and vice versa. This would allow a different approach to setting the PID or at least making a PID assumption.