LCD Weekly: Simu and Reco 5/17/05 SLAC NG (Norman) TJ (Tony) JM (Jeremy) SM (Steve) RC (Ron Cassell) JS (Jan) WL (Willy Langeveld) MM (Matt ?) --- JM: Update on LCIO input to SLIC. TJ: Update on SLIC GUI. NG: New tracker raw hit formats. WM: [slides] Second pass on clustering. Merging cores (those with min # hits --> 5 right now) w/ fragments. Merge cluster cores in case see 1 MC contrib to > 1 cores. Want to use MST algorithm: fast, simple, recursive. Reuse for 2nd pass. Current implementation: user provides metric to define distance between hits. Current: CalorimeterHit->AbstractCluster Needed: AbstractCluster->AbstractCluster Use CalorimeterHit or AbstractCluster? Change interface to metric? NG: Add method with different signature? WM: Call in recursive algo. GetDistance which takes 2 hits. Supposed to be provided by user metric. User has not provided actual implementation w/ AbstractClusters. Solution: Class based on AbstractCluster and derived from CalorimeterHit. SM: Same here -- don't want to use CalorimeterHit. Want to use "anywhere I want". NG: Go ahead and change -- small user base. WM: [plot f/ slides] Closest core usually from same MCParticle. Nice improvement in Eres with cluster cores w/in 20 cm. First step that Niels investigated. Succeeded in generalizing the code to take AbstractClusters rather than hits. Just something that has to be derived from AbstractCluster. Status: MST package generalized. Now explore how to merge small clusters, large clusters, fragments, single hits, etc. Need to look at performance. CVS update soon. TJ: When combine clusters, keep any record of old clusters? WM: Keep one clusters and adds hits from one to another and deletes the previous one. TJ: In org.lcsim, clusters can be chained. WM: Ron told about this. TJ: When move to new framework, make obvious how to do it. RC: Make new clusters instead of deleting old ones. WM: Hadn't thought about it, but sounds like good idea. SM: One goal is to see how pure the cluster is when doing the merging? Wondering if should be standard tests to apply to clusters? WM: Particle purity = 1 MCP contributing most of E. Not too many cluster cores where main contributing MCP is the same. Still looking at these quantities. After combining cluster cores w/in 20 cm, number of pure clusters drops by 10%. Don't currently have quantification. SM: When merging, purity gets worse but resolution (?) gets better. WM: User can set minimum number of hits for cluster. User can also set merging distance, 10 cm, 20 cm, etc. Don't really like current way of using geometrical distance because might be different for various particles. MM: Still looking at things at clusters and fragments. We should try to understand what is going on but don't overoptimize. Optimize on jet energy resolution but not there yet. NG: Ron have any comments on org.lcsim? RC: Structures and interfaces are there, so need to "put some meat on it" to make it work. NG: One major things is that clusters are made of clusters -- built in. Don't have to do bookkeeping. Just compose clusters of other clusters. Steve? SM: Helix routine works -- numbers in mm, was using cm in old code. Results with SiD, have some dianostic output that works e.g. perfect particle flow output. NG: RC put time in cluster diagnostic. RC: As soon as get cluster interface, do cluster diagnostics. Wrote code for it, but doesn't work inside org.lcsim w/ LCIO files. SM: Don't know which cluster you want to use. Leftover hits -- might want to cluster somehow. What clusterer to use? Might be nice to evaluate a cluster and determine which algo to use. NG: JS? JS: Started piecing things together and wrote test code. Need to split up and need to make smaller component tests. Reading fast MC tracks and try to fit. NG: Size? JS: JetFinder doesn't work with tracks or MCParticles anymore. Doesn't implement IHepVector. TJ: Put example into bug fix report. JS: Track extend 3Vector? TJ: Track not really a 3Vector. Easy to have it separate and get the 3Vector and put into JetFinder. JS: J/psi -> mumu sample, doesn't work. Tricky to run step-by-step inside of JAS. TJ: Change HelixSwimmer to use mm instead of cm. Status of swimmer f/ SM? SM: Maybe know now what variables to use? JS: zvSwimmer still uses zvTrack parameterisation. Migrating old code to org.lcsim. Trying to make it indepedent by using getMomentum(), etc. from track interface. Also undecided about what to do with tracks passed to the vertexer. Change the original tracks? Old implementation just copied everything and returned zvTracks. TJ: Parameters were changed to go through vertex? JS: Old track copied to zvTrack and did everything with it. NG: Bias is to leave the original tracks alone. ReconstructedParticle gets new track parameters. Old tracks get flagged so don't get used again. Original track list should remain "inviolate" throughout. JS: When get something from vertex, could be different than input. TJ: Might want to keep list of vertex-constrained tracks. Might want to use LCRelation to connect them. NG: Missing pT, etc. want to use the fitted and not original ones. TJ: Just redo vertexing, then want to have access to old ones. JS: zvTrack has pointer to original track. One constructor takes track. Right now, need to instantiate zvTrack from the track. Outside interface should just be from track. MM: Nice to be able to get refitted and original tracks very easily. BaBar didn't do this way. NG: Always good to hear lessons learned. NG: Updates f/ TJ? TJ: Updated org.lcsim event display to display tracks. HelixSwimmer. Started to look at track parameterisation issue. At the moment, "worst of both worlds", fixed set of parameters. Hard to use. No flexibility to use different coordinate system. Want to separate track parameters into separate class. JS: zvTrack has parameter class. TJ: Should reference point be part of track parameters? Track parameters don't make sense w/o reference point. 5 track parameters: position (position of closest approach to reference point), momentum, ... All sets of track parameters will always have a reference point? NG: Best to think of surfaces w/ different types of track parameterisations. TJ: But can't convert into point plus momentum vector. NG: Always needs "something else". TJ: Always be a reference point? JS: I would put reference point into set of parameters. Need to give it a bit of thought. NG: Should have track "pow-wow". JS: Looked at translation from old to new parameters. Seems to be reasonable. Can show some plots. Do get track from the event and plot momentum and reference point -- match between two sets. Old - new -> width is > than expected but seems reasonable.