Minutes for LArSoft coordination meeting on Feb 12, 2019

Present | Herb Greenlee, Robert Hatcher, Kyle Knoepfel, Saba Sehrish, Erica Snider|

Remote | Vito Di Benedetto, Katherine Lato, Gianluca Petrillo, Leon Rochester, Paul Russo, Yun-Tse Tsai, Tracy Usher, Mike Wang|

Release and Project status report [Erica Snider]

• larsoft v8_08_00 released Feb 8
  • createEngine return reference related updates
  • Ability to iterrate over ChannelID_t with in a TPC
  • Updates to showeer track fits
• this week release will include a new GeometryBuilder class and space charge service interface improvements
• next week: will work to accomodate MicroBooNE production release freeze schedule
• art v3_02 is available, decouples art libraries from root among other breaking changes as listed on the art breaking changes page
• LArSoft migration time frame is end of Feb

Conclusion:

• Genie v3 migration
  • Do not know. Waiting for sign off from experiments, but have only heard from MicroBooNE
  • [Herb]: they do not know when they will be ready to sign off
  • [Erica]: we need all experiments before we migrate. Might consider only the MicroBooNE production branch if necessary.
• LArSoft data ovelay workshop on March 4
  • Register here

Status of Multithreaded LArSoft Work [Michael Wang]

• Goal is to refactor LArSoft services and modules to enable thread safety and hence the use of art v3 multithreading capabilities
• Using LArFFT service and CalWireDUNE module as a test case
• Deconstrtucting deconvolution: a complex call graph for the Deconvolute member function
• Replace services with a new class (SignalShaper) that has a deconvolute metthod
• Used tbb parallel_for to parallelize loop over wires
• Showed performance results: Processing time per event: 8 times imprrovement
• Virtual memory increases with number of threads (1.5 GB to 3GB for 20 threads)
• Last side included plans for the next steps

Questions:

• [Herb]: are you using art v3 multithreaded features?

• Answer: No, Deconvolution loop over wires is done in parallel using tbb, we are not running parallel events at the moment.

• [Kyle]: the pattern of replacing service with class is not specific to the module

• [Herb]: Is fftw3 is not threadsafe?
• Answer: the actual calculation of the fftw is threadsafe but the planning phase is not.
• noted that it will an important topic for the upcoming workshop

• [Gianluca] Instructions/lessions learned on the use of thread sanitizer should be provided

Conclusion:

• This is a work in progress.

Towards a 2D Drift Simulation in LArSoft [Leon Rochester and Tracy Usher]

• Builds response on wires based on sum of point sources along track, where the point is defined by a single G4 step
• Divide volume into two regions: a drift region with negligible signal induction, and a second region which defines the response
• Placed at 10 cm from anode at present
• Simulated through the 5th adjacent wire, where there is qualitatively negligible response
• Noted that at ends of tracks, expect to see ghost response on wires just beyond the end of the track
  • Don't know whether we see these artifacts in the data after deconv.

• not modeling 3D drift paths

• Tracy discussed running it in LArSoft with a proof of principle
• Uses SimDriftElectrons module
• Investigated using new LArG4 re-factoring, but involved changes to geometry that he did not know how to do, even after reading the documentation
• [Erica] suggested he work with Hans about doing this. We tried to make it easy, so need to understand where the documentation, procedures, or tools are missing that would make it a tractable problem for people.
• Details on LArSoft implementation
  • Refactored SimDriftElectrons to use art tools to do the electron drift and wire plane response, separately
  • Response tools and Drift tools
• Proposed solution
  • define a new output data object that is strictly a waveform containing the number of electrons per tick on the wire
  • Starting point was to clone the existing Wire.h object used in the reco
  • Keep SimChannels for truth matching
• Detector simulation: Takes simulated waveform, convolves with electronics response
• Current implementation is too slow, need to understand an efficient way to implement this scheme
• Notes
  • Prepared for ICARUS
  • Want this on time scale for March in prep for SBN workshop.
  • Major round of processing for this to start soon.
• Comments from Leon
  • Need about 5 wires on average and 10 time ticks in general, so a factor of 20 over 1D
  • "Trivial" extension to 3D anode geometry just by adding to the point response functions. So would add another factor of 5 in the size
  • Another perfect place to use some sort of HW accelerating

Conclusion:

• Erica will schedule a discussion about how the simulation workflow is factored, and discuss whether a new data product is needed, whether SimChannel is needed, etc.