February 2018 Offline Leads meeting

leads

Offline Leads meeting on February 14, 2018

Attendees: Heidi Schellman, Tracy Usher, Erica Snider, Katherine Lato

A) Discussed Supporting LArSoft on Mac OSX via Docker  

  1. There was a demo at the 1/30/18 Coordination Meeting of using Docker along with other VM technologies to build LArSoft code under SLF6 under Mac OSX. Members of DUNE have proposed this as a way to support LArSoft development under Mac OSX.
  2. Discussed how to proceed. All agree on the importance of supporting development on the Mac. Should we continue investigating this with possible implementation?
    • Q:  What are the problems with cvmfs?
      • A:  There can be huge latencies while waiting for things to cache, even with simple commands. Tuning the cache might alleviate some of this, but if there are frequent release updates (which there are), then it might still be disruptively slow (since pre-caching is not an option). Smaller repositories would help too, particularly for DUNE, but that is not a general solution.
    • Q: do you use local installs or CVMFS for developing on Mac
      • A:  Most seem to do local installs. Debugging capabilities are more difficult if not built locally.
    • Q: How often do you update the release you’re developing against?
      • A:  People seem to do this often. If the code isn’t stale, there’s less pain with merging in changes. Especially when things are complicated. When updating weekly, it just takes 20 minutes to build in the background while you’re doing something else. This way, it does not interfere with development work, which is in contrast to cvmfs cache updates, which occur on demand during development work.
    • All agreed that one of the major concerns for those developing on Mac OSX is access to Mac-based IDEs and other development tools. Docker interferes with xcode, for instance, so that could not be used. The Docker proponents have been asked to investigate this issue. Even if they can be run, they will be less capable than with closer-to-native builds under Mac OSX. Native clang builds would be best. Erica and Tracy both think that supporting native Clang would be nice. Ensuring that the product stack was consistently built is an issue, though more so for production releases than for development. Native clang support is not a priority at the moment.
    • Encouraging native Mac development as a whole is a good thing. Things that run in the production environment need certainty. Things like the event display should be run locally.
  3. Consensus from DUNE and MicroBooNE:  Docker could be used to run LArSoft in non-standard environments, or to gain access to resources that are not otherwise available. It should not, however, be used as a way to support development on Mac OSX.

B) ProtoDUNE support. LArSoft wants to ensure that we are doing what is needed in the short term and consistent with long-term plans. LArSoft has changed the geometry to support different drift directions and changes to Global Wire Coordinates, other changes had to be on the protoDUNE side. With Robert Sulej’s departure, aren’t sure if things are acceptable or if people are complaining about things needed in LArSoft.

  1. Heidi- we ran on MonteCarlo and people were pretty happy. First actual data has come out of the cold box. At the next collaboration meeting in two months, there will be more discussion.
  2. LArSoft encourages people to talk to Erica, Gianluca, or put in a ticket if there are any issues or potential issues. We want to keep the engagement and make sure people have a positive experience with LArSoft.
  3. Heidi thought that giving experiment service credit for working on LArSoft items was mentioned as a good idea.

C) LArG4 update. Met with Hans last week. There are two big pieces–changes to Geant4 side and on the experiment side. Changes to Geant4 side mean that LArG4 doesn’t need to have a copy of the Geant4 code that was made several years ago. Get away from having a custom physics list in order to take advantage of those in Geant4. Tracy recently talked to Bill Seligman, who is working on the experiment-side component, and Hans, who is doing the Geant4 work. Bill is waiting on the Geant changes, but is otherwise ready to test his code. The re-factoring is blocking Wirecell testing. MicroBooNE may need a Plan B.

D) Update on 3D reconstruction workshop.

  1. 3D pattern recognition workshop – 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.
  2. Alan Bross (who is part of Argon Cube) is interested in having the ALICE  pixel people there. The Alice people won’t be in the US, however, so want it to be at CERN. The US people want it to be here.
  3. At a minimum, want all parties to agree on the interface layer between the low-level 3D data and the 3D pattern recognition. This preserves the possibility of sharing downstream pattern recognition code.  The plane readout people have to get to this point by merging 2D data. The pixel people start from this point. The common part of the workshop is then talking about the downstream piece.
  4. Maybe have a joint early morning meeting in the US with remote CERN participation, then have the rest of the workshop in the US without them?  
    • Will pitch this.

E) Profiling – LArSoft team continued examining profiling results for ProtoDUNE, 35t and FD production workflow chains compiled by Soon Jun Yun. Asking DUNE to provide a person to review the results in more detail with LArSoft team and identify actionable bottlenecks. Sent email to Heidi and Tom.

F) Round Robin sharing.

  • Talked about Event Display requirements. Tracy thinks Cory Adam’s model is good, but he has hard-coded in geometries.
  • Fyi – new Macs may not be Intel based. May be issues with that.

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