LArSoft Coordination Meeting

US/Central
FNAL

FNAL

Erica Snider (Fermilab)
Description

To connect via Zoom:  Meeting ID 831-443-820

(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:

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:  WH1E

Support

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

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.
There are minutes attached to this event. Show them.
    • 09:00 09:15
      Release and project report 15m
      Speaker: Dr Erica Snider (Fermilab)
      Slides
    • 09:15 09:35
      Status of multi-threaded LArSoft work 20m
      Speaker: Dr Michael Wang (Fermilab)
      Slides
    • 09:35 10:05
      Exploring a 2D drift simulation in LArSoft 30m
      Speakers: Leon Rochester (SLAN), Tracy Usher (SLAC)
      Point Source Simulation
      Slides