Minutes of the June 26, 2013 LBNE simulations/reco meeting Present: Tom Junk, Matt Szydagis, Maxim Potekhin, Tyler Alion, Kevin Wood, Norm Buchanan, Ryan Wasserman, Andrea Shacklock, Mark Convery, Qizhong Li, Herb Greenlee, Rick Snider, Jonathan Insler, Zepeng Li, Josh Klein, Stan Seibert, Sanjib Mishra, Jim Stewart Apologies to those omitted. Jonathan has been working on a module that performs the operations of unpacking, deconvoluting, and hit-finding all in one operation. The reason for this is so we do not have to make a recob::Wire object in the event record which takes a lot of memory, and is largely empty. Jonathan Asaadi has promised to make an alg out of GausHitFinder, but for now, Jonathan I. has put a snippet of the hitfinder code in his own moduele. Since the zero-suppressed data are stored in blocks of consecutive ticks, it is natural to perform the deconvolution in the time domain. Jonathan will extract the time-domain deconvolution kernel from the signal shaping service, truncate it so that a finite duration set of raw data samples deconvolutes into a finte deconvoluted data set, and pass that on to the GausHitFinder one block at a time. The truncation length of the kernel is fcl-controllable, currently defaulting to 30 ticks. Tom suggests plotting the kernel and comparing it against the inter-plane spacing divided by the drift velocity. A narrow pulse of charge should have an impact on the wire signal bounded by that amount of time (possibly both before and after the passage of the charge). Jonathan had to write a new constructor for recob::Hit to allow it to be produced without an associated recob::Wire. Jonathan has also upgraded the zero suppression to include the measured ADC values before and after a block of values above threshold, commonly called "nearest neighbor readout" mode, though the number of ticks to read before and after the block is fcl-controllable, and tested it. Jonathan is also investigating low-charge hits that Tyler found in the MC. Stan asks if this is nearest neighbor in time or in space. Currently it is in time, but we can imagine also writing ADC's out on neighboring wires if an unsuppressed value was written on that tick. Stan said that nearest-space-neighbor writing is more difficult in the DAQ, since electronics modules would have to communicate with each other. Tyler has been working on disambiguation algorithms using clustering. We have had mixed luck with hit-based disambiguation -- in busy events with showers, there are many combinations of U,V,Z hits and it is easy to get the wrong one. Tyler has started running 2D clustering algorithms on the channel data first, and disambiguation is done on the clusters. Tyler tried out several clustering algorithms -- DBScan, Kinga cluster, and Fuzzy clustering, finally settling on fuzzy clustering as it is quite general. Unfortunately, the geometry of the induction planes in LBNE make the mapping of channel number to spatial position discontinuous. Tyler has modified the fuzzy cluster metric to wrap around. He is consulting with Ben Carls on how to make this general so that we can re-use the same code and not have to split it off. The hits in a cluster are likely to be together spatially, which helps the disambiguation process immensely -- some parts of the cluster may be easier to disambiguate than others, and the ambiguity choice can be carried over for neighboring hits. The clustering may just end up getting called twice, once for disambiguation and once again during the rest of reconstruction, or Tyler can save the pattern-recognition stage clusters in the event record. We also seek characterization of the performance of the algorithm. Tyler and Kevin have started writing an analysis module that tallies up the fractions of correctly and incorrectly disambiguated hits. We would like to generalize this to an analysis module that reads the output of the tracking and calorimetry modules and accumulates energy histograms for estimating energy resolution. Jim Stewart wants to know what the impacts of wire angles of 45 degrees vs. 36 degrees has on energy resolution. Sanjib is interested in the energy resolution of pizeros as a function of pizero energy. Tom suspects that the mechanism by which disambiguation affects energy resolution is if a cluster is divided into pieces, only some of which are accumulated in the energy sum, and that the first attempt at this with full simulation and reconstruction will not be our last attempt and may not be that exciting for physics sensitivity. Zepeng has been working on photon detector digitization and a raw event display. In LBNE, we have nominally 1200 paddles, and >90,000 time samples per channel. This poses an interesting problem for a raw data display, as it is more pixels than can fit on a screen. Zepeng showed a display of a muon event that traverses the volume viewed by four APA's, with the time axis extending a few microseconds. We suggested that zero suppression be implemented for the PD digitization -- even though it represents less data than the TPC, we still win big in data savings. Zepeng asked about PD geometry in the 35T prototype. Tyler has put code int he geometry perl script but disabled it until a final design is available. Jim Stewart said Dave Warner of CSU has the plans for where the paddles are located. Tom showed some slides from the meeting last week with ICARUS collaborators. We need help with reconstruction, as well as cosmic-ray modeling. Danele Gibin showed details of ICARUS's mixture of automatic and visual scan reconstruction, focusing on the automatic parts. For the physics measurements, cosmics are rejected automatically, event objects are identified visually, and automatic methods are used to reconstruct the event objects. A nice feature of ICARUS's reconstruction is that they can get 18% resolution on muon energies just from multiple scattering. Paola Sala outlined areas in which ICARUS and LBNE can collaborate on software. At the meeting, Carlo Rubbia proposed that ICARUS share raw data with LBNE in order to test reconstruction algoirithms with real data and not just MC. We plan on starting this conversation. It will require us to unpack, apply fixes, deconvolute, and find hits in ICARUS data. We also need ICARUS geometry defined in LArSoft.