March 2018 Offline Leads Meeting Notes

The March 2018 Offline Leads status update was handled via email and a google document. 

LArSoft – Erica Snider

The code integration model for LArSoft will become more complicated as more experiments approach data taking. Already an issue for MicroBooNE / Pandora. We will continue to explore this issue with the experiments over the coming weeks.

Have collected input on requirements for the LArSoft event display. This is the first step of investigating a long-term solution for a common LArSoft event display framework to replace the existing display.  The plan for this investigation is documented and tracked in LArSoft issue 19034, and is summarized below:

  1. Develop a set of requirements, ranked according to the following categories:  essential, strongly-recommended, desired, and possibly-useful.
  2. Get community input on the ranking and final list of requirements at two LArSoft Coordination meetings to ensure that people can give opinions.
  3. Establish criteria to judge between the technical options, and review these with the community.
  4. Identify a list of possible technologies such as Root, Venu, ParaView, QT and other potential technologies and how applicable they are.
  5. Compare technologies. Ideally, write a toy display that demonstrates the requirements, or sufficient subset of critical requirements. Code it up on each platform
  6. Evaluate based on established criteria in task 19037
  7. Take the results to SCD management for review, along with an initial deployment proposal and a request for funding.

Gianluca is leaving soon. Working on replacement issues.

DUNE – Andrew John Norman, Heidi Schellman

We’re still gearing up for DC2 in April and ProtoDUNE data in the Fall.  One question relevant to the event display, since it is root based, is whether we could take advantage of the ROOT web interfaces instead of the xvnc to view.  and  describe the interface.  

ICARUS – Daniele Gibin

Progress is continuing with development of simulation and reconstruction in the LArSoft framework. ICARUS now has a light simulation and is able to produce optical hits. The full reconstruction chain has been implemented using TrajCluster, we are not yet able to use Pandora due to an artificial requirement that one of the wire planes in the TPC must have vertical wires (ICARUS has horizontal wires). The Pandorans are aiming to fix this soon.

The LArG4 refactoring by Wes Ketchum is needed/desired before making further improvements to the ICARUS detector simulation.

Due to the LArSoft event display being broken with the introduction of the new version of art in LarSoft v06_70_00, ICARUS is currently basing its work on LArSoft v06_69_01.

LArIAT – Jonathan Asaadi

No Report

MicroBooNE – Herbert Greenlee, Tracy Usher

MCC8 is in the analysis phase with final tweaks for special data sets.

Planning for MCC9 is essentially complete with an aggressive timeline to achieve improvements aimed at results for Summer 2019.

In both cases the version of LArG4 refactoring provided by Wes Ketchum will be necessary, it would be good to include this code on the LArSoft development branch as soon as practicable.

SBND – Roxanne Guenette, Andrzej Szelc

We have run into problems running the optical simulation. Up to now we have been using simphotons, but this has turned out to cause problems in the newest software release version because of memory. LitePhotons were used instead, but most of our infrastructure for timing and reflected light does not work with those.

We are now trying to figure out how to solve this problem. Potentially Wes’s refactorization may help, although we need to look closer into that.

We have first results of matching TPC tracks with Cosmic Ray Tracker ones, which will be useful in future analyses.

We have setup File transfer and SAM definitions (thanks to help from SCD) and are beginning to use that in running our jobs.

Open issues:

  1. Restructuring of LArG4 – Hans Wenzel and William Seligman continue to work on this.
  2. Can NumPy and SciPy have standard, LArSoft compatible distributions made available?
  3. Selective loading of detector data. For DUNE FD want a functionality to load into memory data products only from selected part of the detector, e.g. selected TPCs; this may be a feature request to art however. Could be a usage pattern in LArSoft, or could be in art. After a meeting with Kyle in February, concluded that to deal with reading in part of the detector at one time we need to create data product instances that are distinguished via their tags, and hide the complexity from users. We’re tracking this in: