Skip to content

Adding truth info for FCC-ee ILD model, add vertex resolutions as inp… - #188

Open
armin-ilg wants to merge 5 commits into
iLCSoft:masterfrom
armin-ilg:master
Open

Adding truth info for FCC-ee ILD model, add vertex resolutions as inp…#188
armin-ilg wants to merge 5 commits into
iLCSoft:masterfrom
armin-ilg:master

Conversation

@armin-ilg

@armin-ilg armin-ilg commented Jul 20, 2026

Copy link
Copy Markdown

…ut arguments, update vertex detector naming scheme to be compliant also with FCC-SEED VXD (backwards compatible with CLD VXD), updating CT_MAX_DIST value to use the same as CLD with smaller beam pipe

BEGINRELEASENOTES

…ut arguments, update vertex detector naming scheme to be compliant also with FCC-SEED VXD (backwards compatible with CLD VXD), updating CT_MAX_DIST value to use the same as CLD with smaller beam pipe
@armin-ilg

Copy link
Copy Markdown
Author

@Victor-Schwan : As discussed, here's the PR with the changes to ILDConfig

Comment thread StandardConfig/production/ILDReconstruction.py
Comment thread StandardConfig/production/ILDReconstruction.py Outdated
Comment thread StandardConfig/production/ILDReconstruction.py Outdated
Comment thread StandardConfig/production/ILDReconstruction.py Outdated
@Victor-Schwan

Copy link
Copy Markdown
Contributor

I have just realized that I have already a MCRecoTruthLinker with the correct collection names in my fork (see https://github.com/Victor-Schwan/ILDConfig/tree/fcc-tracking). Further, I assume we wanna place the MCRecoTruthLinker in a HighLevelReco_FCCee similar to the ILC reconstruction (see

MyRecoMCTruthLinker = MarlinProcessorWrapper("MyRecoMCTruthLinker")
MyRecoMCTruthLinker.ProcessorType = "RecoMCTruthLinker"
MyRecoMCTruthLinker.Parameters = {
"CalohitMCTruthLinkName": ["CalohitMCTruthLink"],
"ClusterCollection": ["PandoraClusters"],
"ClusterMCTruthLinkName": ["ClusterMCTruthLink"],
"FullRecoRelation": ["true"],
"KeepDaughtersPDG": ["22", "111", "310", "13", "211", "321"],
"MCParticleCollection": ["MCParticle"],
"MCParticlesSkimmedName": ["MCParticlesSkimmed"],
"MCTruthClusterLinkName": ["MCTruthClusterLink"],
"MCTruthRecoLinkName": ["MCTruthRecoLink"],
"MCTruthTrackLinkName": ["MCTruthMarlinTrkTracksLink"],
"RecoMCTruthLinkName": ["RecoMCTruthLink"],
"RecoParticleCollection": ["PandoraPFOs"],
"SimCaloHitCollections": [
"BeamCalCollection",
"LHCalCollection",
"LumiCalCollection",
CONSTANTS["ECalSimHitCollections"],
CONSTANTS["HCalSimHitCollections"],
"YokeBarrelCollection",
"YokeEndcapsCollection",
],
"SimCalorimeterHitRelationNames": [
"EcalBarrelRelationsSimRec",
"EcalEndcapRingRelationsSimRec",
"EcalEndcapsRelationsSimRec",
"HcalBarrelRelationsSimRec",
"HcalEndcapRingRelationsSimRec",
"HcalEndcapsRelationsSimRec",
"RelationLHcalHit",
"RelationMuonHit",
"RelationLcalHit",
"RelationBCalHit",
],
"SimTrackerHitCollections": [
"VXDCollection",
"SITCollection",
"FTD_PIXELCollection",
"FTD_STRIPCollection",
"TPCCollection",
"SETCollection",
],
"TrackCollection": ["MarlinTrkTracks"],
"TrackMCTruthLinkName": ["MarlinTrkTracksMCTruthLink"],
"TrackerHitsRelInputCollections": [
"VXDTrackerHitRelations",
"SITTrackerHitRelations",
"FTDPixelTrackerHitRelations",
"FTDSpacePointRelations",
"TPCTrackerHitRelations",
"SETSpacePointRelations",
],
"UseTrackerHitRelations": ["true"],
"UsingParticleGun": [str(using_particle_gun).lower()],
}
) and not in the ILDReconstruction.py. This is also already present in my fork. I guess it may make more sense to take the MCRecoTruthLinker from my fork?

Co-authored-by: Victor Schwan <162138084+Victor-Schwan@users.noreply.github.com>
@armin-ilg

Copy link
Copy Markdown
Author

I have just realized that I have already a MCRecoTruthLinker with the correct collection names in my fork (see https://github.com/Victor-Schwan/ILDConfig/tree/fcc-tracking). Further, I assume we wanna place the MCRecoTruthLinker in a HighLevelReco_FCCee similar to the ILC reconstruction (see

MyRecoMCTruthLinker = MarlinProcessorWrapper("MyRecoMCTruthLinker")
MyRecoMCTruthLinker.ProcessorType = "RecoMCTruthLinker"
MyRecoMCTruthLinker.Parameters = {
"CalohitMCTruthLinkName": ["CalohitMCTruthLink"],
"ClusterCollection": ["PandoraClusters"],
"ClusterMCTruthLinkName": ["ClusterMCTruthLink"],
"FullRecoRelation": ["true"],
"KeepDaughtersPDG": ["22", "111", "310", "13", "211", "321"],
"MCParticleCollection": ["MCParticle"],
"MCParticlesSkimmedName": ["MCParticlesSkimmed"],
"MCTruthClusterLinkName": ["MCTruthClusterLink"],
"MCTruthRecoLinkName": ["MCTruthRecoLink"],
"MCTruthTrackLinkName": ["MCTruthMarlinTrkTracksLink"],
"RecoMCTruthLinkName": ["RecoMCTruthLink"],
"RecoParticleCollection": ["PandoraPFOs"],
"SimCaloHitCollections": [
"BeamCalCollection",
"LHCalCollection",
"LumiCalCollection",
CONSTANTS["ECalSimHitCollections"],
CONSTANTS["HCalSimHitCollections"],
"YokeBarrelCollection",
"YokeEndcapsCollection",
],
"SimCalorimeterHitRelationNames": [
"EcalBarrelRelationsSimRec",
"EcalEndcapRingRelationsSimRec",
"EcalEndcapsRelationsSimRec",
"HcalBarrelRelationsSimRec",
"HcalEndcapRingRelationsSimRec",
"HcalEndcapsRelationsSimRec",
"RelationLHcalHit",
"RelationMuonHit",
"RelationLcalHit",
"RelationBCalHit",
],
"SimTrackerHitCollections": [
"VXDCollection",
"SITCollection",
"FTD_PIXELCollection",
"FTD_STRIPCollection",
"TPCCollection",
"SETCollection",
],
"TrackCollection": ["MarlinTrkTracks"],
"TrackMCTruthLinkName": ["MarlinTrkTracksMCTruthLink"],
"TrackerHitsRelInputCollections": [
"VXDTrackerHitRelations",
"SITTrackerHitRelations",
"FTDPixelTrackerHitRelations",
"FTDSpacePointRelations",
"TPCTrackerHitRelations",
"SETSpacePointRelations",
],
"UseTrackerHitRelations": ["true"],
"UsingParticleGun": [str(using_particle_gun).lower()],
}

) and not in the ILDReconstruction.py. This is also already present in my fork. I guess it may make more sense to take the MCRecoTruthLinker from my fork?

Okay, yes that makes totally sense. Shall I remove the truth link stuff from this PR?

@Victor-Schwan

Copy link
Copy Markdown
Contributor

Okay, yes that makes totally sense. Shall I remove the truth link stuff from this PR?

In my opinion, that makes the most sense. If you need it, just cherrypick it from my PR. This way, git is aware of it and there shouldn't be any conflicts later on

@tmadlener

Copy link
Copy Markdown
Contributor

So for clarification: This PR will introduce the vertex resolution setting bits and #193 will do the truth linking?

Comment thread StandardConfig/production/Tracking/TrackingDigi_FCCeeMDI.py
Comment thread StandardConfig/production/Tracking/TrackingReco_FCCeeMDI.py Outdated
Comment thread StandardConfig/production/Tracking/TrackingReco_FCCeeMDI.py
@Victor-Schwan

Copy link
Copy Markdown
Contributor

So for clarification: This PR will introduce the vertex resolution setting bits and #193 will do the truth linking?

There are many things in #193 that are necessary for FCC tracking. I've created a draft PR so that others can see it and, for example, to avoid implementing TruthLinking twice. However, it might make sense to merge TruthLinking beforehand in a separate PR. Let me know if you wish to do so

@tmadlener

Copy link
Copy Markdown
Contributor

However, it might make sense to merge TruthLinking beforehand in a separate PR. Let me know if you wish to do so

That sounds like a good idea

@armin-ilg

Copy link
Copy Markdown
Author

So for clarification: This PR will introduce the vertex resolution setting bits and #193 will do the truth linking?

There are many things in #193 that are necessary for FCC tracking. I've created a draft PR so that others can see it and, for example, to avoid implementing TruthLinking twice. However, it might make sense to merge TruthLinking beforehand in a separate PR. Let me know if you wish to do so

I removed the truth linking from this PR 👍

@armin-ilg

Copy link
Copy Markdown
Author

All comments addressed now

Comment thread StandardConfig/production/Tracking/TrackingReco_FCCeeMDI.py
Co-authored-by: Thomas Madlener <thomas.madlener@desy.de>
@tmadlener

Copy link
Copy Markdown
Contributor

CI seems to be as happy as we expect it to be. @Victor-Schwan any preference from your side on the order of merging things?

@Victor-Schwan

Copy link
Copy Markdown
Contributor

As this is based on #197, #197 should be merged first. I assume you also take care of merging #194 and then it is up to you what you prefer :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants