To connect via Zoom: Meeting ID 831-443-820
Password distributed with meeting announcement
(See instructions for setting Zoom default to join a meeting with audio and video off: https://larsoft.org/zoom-info/)
PC, Mac, Linux, iOS, Android: https://fnal.zoom.us/j/831443820
Phone:
https://fnal.zoom.us/zoomconference?m=SvP8nd8sBN4intZiUh6nLkW0-N16p5_b
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
213.19.144.110 (EMEA)
See https://fnal.zoom.us/ for more information
At Fermilab: no in-person presence at the lab for this meeting
Release and project report
Dropping python 2 build: no comments at meeting. Suggest email to larsoft@fnal.gov, wait a week, then move ahead
Ed Tyley: TRACS to ModuleShower
PFPs classified as track-like of shower-like
Showers go through shower characterization, then create recob::Shower
Two algs for this
EMShower
PandoraShower
topology only
TRACS: Tool-based Reco Alg for Characterizing Showers
First discussed at Coord meeting Aug 13, 2019
Dev’d by Dom Barker, Ed, Dom Brailsford in SBND
Provides a modular framework to fully create a recob::shower from PFP input (pandora)
Runs over a set of art::Tools
Each should calc one thing (eg start position)
Can change which methods are used in fcl
Create a suite of tools w many diff approaches
Use ShowerElementHolder to pass info between tools
Currently used as the main shower reco in SBND and ICAUSR (Tom Ham and Bruce Howerd)
Has been used in DUND FD (D Brailsford)
Tech details
A LArSoft producer module
initialize the tools based on param list
manages ShowerElementHolder for passing info between the modules and tools
Runs through tools for each PFParticle
Retreives the shower params from ShowerElementHolder
Creates recob::Shower an adds assns (Shower <—> Hits)
SEH is a map to templated base class w set(), get() and check() functions
Can store any object here, not just things in recob::Shower
eg. one tool calcs and stores subset of hits for calc dE/dx in another tool
Can store Element and Uncert for things that require errors in recob::Shower (eg, shower energy)
Tools
Derived from base class IShowerTool
has access to alg w commonly used functions
Each aims to do one thing (eg, start pos, direction, dedx, energy,…)
Can create assns from w/in tools
assns from Shower to recob::PCAxis in ShowerPCADirection tool
someone who has an idea for shower reco should create a new tool and not deal with the module or ShowerElementHolder (Skeleton and example tools exist to help people get started)
The problem and solution: LArPandoraModularShowerCreation
Move to LArPandoraModularShowerCreation (change of name and location)
Circ dep prevented the PandoraSlidingFit tool
Moved from larreco to larpandora to overcome this
Should increase usage accross experiments
Will live longside LArPandoraShowerCreation
Expts must opt-in (eg, no changes unless desired)
Validation:
Can reproduce LArPandoraShowerCreation from LArPandoraModularShowerCreation
Produces some extra showers where LPSC failed
Expts will need to configure to use their CalorimetryAlgs
Improvements over TRACS
Can now push PandoraSlidingFit and related tolls
Functions to store FinaManyP objects in ShowerElementHolder (signific speed-up)
Simplified config: make tools inherit fcl params from module
Renamed some tools
bug fixes + doc improvements
Expt changes
TRACS being removed is a breaking change for experiments that use it
SBND and ICARUS have branches that address this
DUNE FD will opt in when D Brailsford is back from holiday
Most tools run out of the box
Need to configure calorimetric tools to use expt specific algs
Showed events displays, some performance metrics
shower start position: comp to EMShowerPerf metrics
shower direction: better than EMShower, comp to legacy PandoraShower
dE/dx: comp to EMShower, though with a slight shift to higher energy for two-mip peak
shower energy ratio (reco / true): comp to EMShower (and all others)
length and opening angle: no comparison to expectation or truth, so can’t tell...
Outstanding issues
Need to update to LARSoft v09
Kyle did this, but not copied over
Discuss applying clang-format to larpandora (same as done in larpandoracontent)
Will follow up w Kyle about this
Change is approved
Bruce Baller: Track calorimetry issues
Testing TrajCluster upgrade to prod tracks w TrackHitMeta and SpacePoints
Test exposed inaccuray in how Calorimetry module uses Track trajectories and THM data
Signific problem for short tracks
The prob: short track calor suffers from several effects
Short = 10-30 points in three planes
Eg, 50 MeV KE protons
Generally at large angle with respect to wire planes
Large wire spacing (eg DUNE) results in large values of dx (pitch > ~1cm in de/dx calc are common)
Transverse diff in long drift TPCs not negligible
~0.3 cm at max drift in DUNE
Calor module assumes track stops directly over a wire on average —> large error in dE/dx vs resid range -> large uncert in PID
Showed example of MC proton w T = 56 MeV, p = 331 MeV, range = 2.9 cm. No SCE
True length = 2.9 cm. Reco length = 5.5 cm. Reco dir error = 200 mrad. Chi2 per ndof = 0.1
So get a really bad result due to integer nature of start / stop points
Similar result from Pandora: True = 2.9, reco = 4.5 cm. Reco dir error = 226 mrad. No chisq
Wanted to investigate better way of estimating start point using Bethe-Bloch in Excel
Used to develop the PIDA alg
Calcs de/dx, E loss, recombination and charge for user-selected step size and init KE
Calculated Q vs wire for proton traversing exactly 6.0 wires, range = 3.025 cm
Start point first centered on wire, then shifted by 0.1, 0.3, 0.4 cm
Showed that
charge at ends changes significantly depending on how far from wire is from true start/end points.
Reco range would be 3.5 cm for almost all cases.
Results in PID error
Refining end point positions
Showed that using charge ratio in last two points might provide better stop point estimate, and so a better range.
Noted should work at start point as well (although vertex region is complicated!…)
Suggests we need a better convention. Should address integer wire accuracy —> better representation for recob::Track start and end pts
By definition at present, traj points are by construction defined at track trajectory intersections with wire measurement plane. So are integer-like
Flags in TrackHitMeta can be used here, can be part of the solultion
Comments, opinions
Flags not fully ustilized by track modules
eg, “NoPoint” flag, “suspcious”, “shared”, “detectorissue”
Suggest TPs that are “shared” not be used for calor
TrackHitMeta provides hit—>Track assn
There should also be a hit—> TP assn
Calor throws an exception if not a one-to-one TrackHitMeta to TP assn
Track start (end) methods return position of the first (last) valid points
Calor module sets stopping point to resid range[0] = 0.5 * track pitch (??)
Suggest instead that the start and end positions be defined by the track module
Implicit that valid traj points are ordered from start to end
Ideally flags and trackhit meta would be packaged in the TrajectoryPoint_t struct
maybe track proxy class would allow this?
Question: should the Start() of a track that is attached to a vertex be the vertex position, or should it be the first valid hit?
[ES opinion: if there is a vertex position available that is determined from a fit of multiple tracks, then that position should be used as the start. Note that this first point in this case, and perhaps a few others near the vertex cannot reliably be used in calorimetry]
Proposal
Insert two special TPs to define the start and end positions
define using an alg like that on slide 9 (last hit charge ratio)
define two new TP flag traits: TrackStart and TrackEnd
No hits are associated w those TP, but they need to be “valid" and be the first and last valid points on the trajectory
requires mods to Calorimetry module, and any other algorithms that perform calorimetry
Hit charge in the (!Valid) TPs outside of start - end range would need to be include in the sum of total track charge [?? …not following this point]
Add an IntersectionPoint method that allows using wires w float precision
Discussion
Need to think about his comments, questions and proposals
Try to connect with communities working on low energy physics, to see where they are, what they are thinking about <<<——— This is v important!
Develop a full proposal for how to address this
Then re-present at LCM with the plan of work