210 likes | 397 Views
CLID ILD Reconstruction Status. Mark Thomson University of Cambridge. This Talk. Status of CLIC_ILD reconstruction path one outstanding cross-check we are ready to tag a release (see Andre’s talk) This is the final chance to comment on Detector timing assumptions
E N D
CLID ILD Reconstruction Status Mark Thomson University of Cambridge
This Talk • Status of CLIC_ILD reconstruction path • one outstanding cross-check • we are ready to tag a release (see Andre’s talk) • This is the final chance to comment on • Detector timing assumptions • PFO timing selection cuts • DST format • Thanks to many people • in particular, Andre for keeping on top of all the small fixes • Erik, Jacopo, Jean-Jacques for finding bugs/features • Stephane for producing files with overlay • … Mark Thomson
Tracking with Overlay • At last meeting still some questions regarding tracking efficiency • with overlay • Ran a quick sanity check: • fire 10 GeVmuons in random directions • use full background overlay • define efficiency “is there a reconstructed track within 0.1 GeV • of 10 GeV which is associated with the MC “physics muon” Histo = MC muon Point = reco 10 GeV track cosQ Mark Thomson
Q [deg] • Limited statistics (no time), but no indication of major problems • Hint of something at 10 degrees: FTD geometry ? • Only 2 tracks from ~1000 with q>7 degrees not reconstructed Mark Thomson
Detector Assumptions • Calorimeters • Assume all hits have a timestamp • currently no smearing of hit times, assumed ~ 2 ns • Assume two hit separation limited to 20 ns • Hits within 20 ns are merged (use time for highest ph hit) • For ECAL/HCAL endcap reconstruction integrate over 10 ns • For HCAL barrel integrate over 100 ns • Silicon • Integrate over time window of 10 ns • No accounting for multiple hit capability • occupancies fairly low • TPC • Integrate over full bunch-train • Require a matched Si hit in the above 10 ns window • For looping tracks, also require arrival at ECAL within 50 ns Defines input to event reconstruction Mark Thomson
Overlay Reconstruction • Can now routinely process events with overlay !!! • few minutes per event • overlay 60 BXs gamma gamma -> hadrons (limited by fortranPatRec) • believe to be a good approximation • accounts for almost all calorimeter background • + TPC PatRec is not an issue (see ALICE reconstruction) • Compare overlay/non-overlay processing for 1 TeV Z event 1.4 TeV of background (reconstructed particles) ! Mark Thomson
PFO Selection • Reconstruction performed at the full overlay level • Then apply optional cluster-based timing cuts • Since clusters contain many hits, mean cluster time known well • assuming single hit resolution of ~ ns implies offline cluster • times typically known to much better than 1 ns • LHC experience suggests this is realistic • e.g. HCAL endcap (where occupancy is high) t/ns Background peaks Around 5ns, i.e. half of the 10ns window pT/GeV Mark Thomson
CLICPFOSelector • Offline cluster time cuts applied in: CLICPFOSelector • calculates a robust mean charge-weighted time for each cluster • (finds median time, rejects outlying 10 % of hits) • applies cuts at PFO level • different cuts for Photons, Neutral hadrons and charged hadrons • if enough hits, time obtained from ECAL • A priori, not clear how extreme the timing cuts should be • Requirements may depend on physics analysis • Part of our study is to determine what is required ! • Hence run three versions of CLICPFOSelector • Default, Loose cuts, Tight cuts • For physics analysis, have four possible sets of PFOs • PandorPFANewPFOS • SelectedPandoraPFANewPFOs • LooseSelectedPandoraPFANewPFOs • TightSelectedPandoraPFANewPFOs Mark Thomson
PFO-based Timing Cuts • For each PFO type define two levels of timing cuts (tight, loose) Default cuts: Mark Thomson
Loose cuts: Mark Thomson
Tight cuts: Mark Thomson
PandoraNewPFAs 1.4 TeV of background ! Mark Thomson
LooseSelectedPandoraNewPFAs 0.3 TeV of background Mark Thomson
SelectedPandoraNewPFAs 0.2 TeV of background Mark Thomson
TightSelectedPandoraNewPFAs 0.1 TeV of background Mark Thomson
AOD Format • Since last meeting, implemented AOD (DST) writing • greatly simplified based on LCIO subsets • now only write out MC particles for Physics event • (not the overlayed background) • Collections kept • tracks • clusters • pfos (x4) • pfo -> mc relation • skimmed mc particles from physics event • Flavour tagging left to the analysis groups Mark Thomson
AOD for single muon + overlay COLLECTION NAME COLLECTION TYPE #ELEMENTS ================================================================ LooseSelectedPandoraPFANewPFOsReconstructedParticle 222 MCParticlesSkimmedMCParticle1 PandoraPFANewClusters Cluster 751 PandoraPFANewPFOsReconstructedParticle942 RecoMCTruthLinkLCRelation 942 SelectedLDCTracks Track 701 SelectedPandoraPFANewPFOsReconstructedParticle117 TightSelectedPandoraPFANewPFOsReconstructedParticle 48 Note: MC relations in AOD have to be used with care only “physics event” MCParticles are retained in AOD Mark Thomson
Using PFO - MC relations LCCollection * col = evt->getCollection(m_inputMcParticleCollection.c_str()); intnelem = col->getNumberOfElements(); for (intiMc=0; iMc<= col->getNumberOfElements(); ++iMc){ MCParticle * pMc = dynamic_cast<MCParticle*>(col->getElementAt(iMc)); m_mcSet.insert(pMc); } LCObjectVecobjectVec = m_pfoToMcNavigator->getRelatedToObjects(pPfo); if (objectVec.size() > 0) { for(unsignedintimc = 0; imc < objectVec.size(); imc++){ MCParticle * pMC = dynamic_cast<MCParticle*>(objectVec[imc]); // since only saving skimmed set of MC particles, // check pMC points to an existing object if(m_mcSet.count(pMC)!=0){ physicsPfos.push_back(pPfo); physicsMatchedMcParticle.push_back(pMC); }else{ backgroundPfos.push_back(pPfo); } } Mark Thomson
Status of ILD Reconstruction • After • all code included in IlcSoft v11-pre02 • will ask DESY make tag very soon • Default “steering” files in StandardConfig/clic_cdr • clic_ild_cdr_steering.xml • clic_ild_cdr_steering_overlay.xml • clic_ild_cdr_pandora_settings.xml • clic_ild_cdr.gear • Plan is to process events with and without overlay to help to • assess impact of background • non-overlay version is almost identical to overlay version Mark Thomson
final steering files NBackground = 0.0 NBackground = 3.2 <execute> <processor name="MyOverlayTiming"/> <processor name="MyCLICCDRMaterialDB"/> <processor name="MyTPCDigiProcessor"/> <processor name="MyLEPTrackingProcessor"/> <processor name="MyVTXDigiProcessor"/> <processor name="MyNewFTDDigiProcessor"/> <processor name="MyETDDigiProcessor"/> <processor name="MyILDCaloDigi"/> <processor name="MySimpleMuonDigi"/> <processor name="MySiliconTrackingCLIC"/> <processor name="MyFullLDCTracking"/> <processor name="MyCLICTrackSelector"/> <processor name="MyV0Finder"/> <processor name="MyKinkFinder"/> <processor name="MyMarlinPandora"/> <processor name="MyRecoMcTruthLinker"/> <processor name="MyLCIOOutputProcessor"/> <processor name="MyDstWriter"/> </execute> Including calo timing cuts Overlay version only MC Skimming for DST Write REC file Write AOD Mark Thomson
Remaining Issues NOTHING SIGNIFICANT* *Need to request a tagged release of ILCSoft Mark Thomson