October 2017 Offline Leads Meeting Notes

leads

October 16, 2017 Notes from Offline Leads’ Meeting with secondary meeting on Oct 18th

Attendance:

  • Herb Greenlee, Tracy Usher, Tom Junk, Erica Snider, Katherine Lato at the first meeting.
  • Heidi Schellman, Tom Junk, Robert Sulej, Erica Snider, Katherine Lato at the second meeting

LArSoft

  • Discussed with the Offline Leads about their doing more of the CI operations. Experiments like the way it currently works, but LArSoft asked them to consider having someone who has a role to look for problems in CI test results
  • LArSoft is requesting  feedback on moving to a GitHub-hosted pull-request system, where request approvers would be selected from the experiments. Also discussed possible code re-organizations and introduction of sparse checkouts that might accompany the GitHub migration.
  • Event display – experiments would like to use Qt (or another framework) to rewrite Event Display. If there was a package or framework to build off of, it wouldn’t be too much effort for experiments to rewrite the Event Display.
    • MicroBooNE has investigated using TEve, but can’t replicate the existing 2D display with that tool, so ROOT isn’t a viable option.  
    • Ideally, LArSoft would provide a sensible framework that could be extended as needed to provide features needed.
    • Cory has an Event Display running off of Qt, but not within LArSoft.
  • Two new sub-projects are being  defined in LArSoft to take advantage of the availability of experts in these areas for the next few months
    • Profiling and optimization work  to identify problem areas and solutions in existing workflows. Will be carried out by Soon Yung Jun https://cdcvs.fnal.gov/redmine/issues/17921
    • Vectorizing optimizations to identify and vectorize appropriate targets across LArSoft to take advantage of resources within our existing computing infrastructure that has not been utilized. Will be carried out by Giulherme Lima https://cdcvs.fnal.gov/redmine/issues/17920
  • Pursuing a date and location for the 3D pattern recognition workshop, the proposal is to couple it to the DUNE Collaboration Meeting at CERN Jan 29 – Feb 1, 2018, so that would be Friday, Feb. 2, 2018. Proposed scope will cover all existing work to produce 3D space points, plus algorithms to perform pattern recognition using space points as input. Will also work toward agreements on data products, interfaces between various workflow stages so that we can continue to share algorithms.
  • LArSoft asked for requirements for LArSoft for 2018, including looking at redmine issues that are accepted redmine issues, but not assigned for things that may be of priority to the experiments.

DUNE

Wirecell people are interested in knowing the data product that will be used as input to LArG4. Note, LArSOft sent email on September 8th asking for feedback.

Introducing support for global wire coordinates is important and is documented in https://cdcvs.fnal.gov/redmine/issues/11522.  Discussed some of the technical requirements.

  • For pattern recognition, if TPCs are aligned near enough, the global wire coordinates make sense.
    • Detector construction alignment tolerances is therefore a critical issue, particularly TPC to TPC rotations.
    • Details are not known yet, but expect mis-alignments to be small compared to wire spacing. What does a global wire coordinate mean when you’re trying to get to 3D via 2D images? If rotations cannot be ignored at pattern recognition phase, then a global wire coordinate is not helpful, since you effectively change coordinate systems as you cross boundaries.
  • Global wire coordinates may have implications for the event display.
  • At present, DUNE has implemented an ad hoc solution to provide global wire coordinate functionality

LArSoft sent DUNE email requesting they identify a major DUNE production workflow that will be the target of the profiling work, and a person in DUNE who will work with Soon Yung Jun, who will provide the resources and connections within DUNE needed.

Architecture-dependent libraries – avx2.

  • Need to support a generic library as well as one built with avx2.
  • TensorFlow may have run into this issue. At present, DUNE is building code with the lowest common denominator, which is sub-optimal
  • There are a lot of areas that will have these types of issues. In general, want to take advantage of resources when they’re there. The solution might also allow use of GPU back-ends when available.

Event display – DUNE would like to see a common event display. It would be nice to be able to navigate through a giant event in a painless way. There is a lot of raw data. It doesn’t fit on the screen. Have to be able to zoom and pan. Very interested in a common event display across LArSoft.

  • LArSoft would like to support development of a new framework for the event display, one that will run in both art and gallery. At present, we do not have effort available for this.

Also mentioned at the meeting:

  • Databases have come up a lot. LArSoft has guidelines for the front-end interfaces used to access databases. LArSoft also recommends using one of the two lab supported back-end packages whenever possible. (They are not part of LArSoft)
  • They are thinking about multi-threading with new code.
  • Discussion with CERN DAC people, how access to SAM meta-data works? Is this an art issue?

MicroBooNE

Have heard that ArgonCube believes they can’t use LArSoft because it can’t handle a pixel detector.

  • LArSoft noted that with the LArG4 redesign, the anode region simulation is abstracted, which allows separate solutions for single phase, dual phase and pixel-based detectors. Erica talked at a pixel meeting and mentioned that LArSoft is restructuring the simulation in this way and stated that it would be possible to handle pixel readouts, though not immediately.
  • They also want to be able to run LArSoft on NERSC, which is not currently possible
    • This might become easier once we have Spack build system, since that is a tool from the supercomputing world

Mentioned Bill Seligman’s work on LArG4.

  • LArSoft is hoping that what he produces will be sufficiently easy to use extensible enough to be something people will want to use.
  • Tracy mentioned that SLAC has people in their Geant4 group who are actively looking for projects. Might want to look into whether we can recruit one of them to work on LArG4 re-factoring. Depends on what Bill is doing, so talk to him first.

Event display – would like to use Qt to rewrite Event Display. Cory has an Event Display running off of Qt, but not within LArSoft.

Could NumPy and SciPy toolkits have a standard distribution? A lot of people use them, could they be distributed so they’re compatible with LArSoft version of python so that people don’t have to download them off the internet?

  • LArSoft will look into developing a process for nominating tools to be included

Please email Katherine Lato or Erica Snider for any corrections or additions to these notes.