Present: James Amundson, Vito Di Benedetto, Lynn Garren, Alex Himmel, Thomas Junk, Robert Kutschke, Katherine Lato, Gianluca Petrillo, Brian Rebel, Saba Sehrish, Erica Snider, Hans Wenzel, Tingjun Yang
Remote: David Adams, Gleb Sinev
Release and project report [Erica Snider]
-
some LArSoft releases were considered "production" by some experiments, but not marked as such
-
as described in art stakeholders meeting, deprecated art features are
-
v06_10_00_rc2 (release candidate) will include fixes to LArG4 to work with Geant4 10.2
-
[Saba Sehrish] planning to develop the
for_each_associated_group() pattern using Range-v3 library
Conclusions
-
please experiments verify that all their LArSoft "production" releases are known by the LArSoft team as such
-
need feedback about current Ubuntu users, and whether the plan to switch support from Ubuntu 14 to Ubuntu 16 (LTS) when the transition to GCC 6 happens (driven by art) is acceptable
-
[David Adams] BNL wants to update to Ubuntu 16
CI operations report [Vito Di Benedetto]
-
is the DUNE CI test workflow the correct one?
-
[Tingjun Yang] the current workflow is for DUNE 35t prototype, we should move to the Far Detector one
-
IFDH client preliminar tests are failing, but they are using a beta release rather than an official package
-
[Lynn Garren] work is being done to address remaining issues
-
the slicer problem in LArIAT may be related to a behaviour change in art
-
[Tingjun Yang] LArIAT would appreciate some guidance in how to address this type of problem
Conclusions
-
will meet with DUNE representatives to define a new workflow
-
need to coordinate the communication between art experts and LArIAT about the file output name rule features
LArG4 support project report [Hans Wenzel]
-
prepared
LArG4 to use Geant4 10.2
-
optical photon process allows Geant4 to generate photons without spelling them out individually
-
[Alex Himmel] we use to ignore Cerenkov light [Hans Wenzel] that is still possible by disabling the pertinent physics process
-
the adoption of
artg4tk would allow an easier interface to simulate the beam line and "auxiliary" detectors
Modularization of DetSim and DataPrep [David Adams]
-
modularised the signal simulation into a main framework module plugging in components at run-time
-
components can also select sub-components at run time
-
[Brian Rebel] what is the difference between a "tool" and an algorithm? [A] tools can be discovered and invoked by the framework
-
[Erica Snider] the "tool" concept is somewhere in art road map
Conclusions
-
Geometry support needs to be completed (issue #9264)
There are minutes attached to this event.
Show them.