Present: Dave Dagenhart, Laura Fields, Lynn Garren, Herbert Greenlee, Alex Himmel, Chris Jones, Thomas Junk, Jonathan Paley, Marc Paterno, Gianluca Petrillo, Brian Rebel, Saba Sehrish, Mike Wallbank, Hans Wenzel, Tingjun Yang
Connected: Vito Di Benedetto, William Seligman
LArSoft project status [Gianluca Petrillo]
-
last release was v04_25_00
-
the coming release will include:
-
interfaced wire cell framework (see Tingjun Yang's presentation today)
-
merged
IChannelStatusService replace ChannelFilter class
-
v04_25_00 had incomplete update
-
in the coming release, we will have complete set of changes
-
renaming of two classes affects FHiCL configuration and code
-
MicroBooNE code should be immune, since it does not use the class being renamed
-
the use of
ChannelFilter class is now deprecated (instructions for update are available)
-
feature branches about
ChannelStatus service are ready for merging
-
on October 20, 2015 a LArTPC Requirements Workshop will take place, and there will be no LArSoft Coordination Meeting
LArSoft update plan for art 1.16 [Lynn Garren]
-
needed for OSX compatibility with the latest Xcode (version 7)
-
requires an updated GCC version (4.9.3)
-
[Marc Paterno] GCC 4.9.3 rejects some wrong code that GCC 4.9.2 erroneously allowed
-
[Jonathan Paley] LArSoft is full of unused instances of
art::ServiceHandle<>
-
new version of python (2.7.10) will be used
-
required by people using numpy and scipy
-
no change in python code is expected to be needed
-
even bytecode should be compatible
-
[Herbert Greenlee] update will require retesting of experiment scripts
-
LArSoft will activate the new
ALLOW_DEPRECATIONS flag
-
as soon as the supporting cetbuildtools v4_14_00 is pulled in
-
art v1_16 product stack will be installed for testing before being used by LArSoft release
-
planning a double release (one before, one after the GCC update)
-
need to hear of remaining OSX Maverick's users
-
Maverick's support will be replaced by El Capitan support (time line: December 2015)
Conclusions
-
need to hear of remaining Maverick's users
Merging wirecell in LArSoft [Tingjun Yang]
-
novel reconstruction developed at BNL, including ah hoc framework
-
code has been already merged in the current LArSoft release (v04_25_00)
-
this code interfaces the external wire cell "package" with LArSoft
-
making whatever wire cell package needs out of wire waveforms
-
making tracks, space points and associations, etc. out of whatever data wire cell package provides
-
need charge information stored (in
recob::SpacePoint)
-
[Brian Rebel] can this be integrated into LArSoft? not clear:
-
it uses a different build system and dependencies than LArSoft (noticeably, ROOT 6)
-
[Lynn Garren] will follow pandora's model
-
[Herbert Greenlee] the input and output procedure is clumsy, requiring multiple conversions
-
[Tingjun Yang] this is the first, quick "solution"; improvements are possible
-
a light-weight web based event display is also included in the wire cell package
-
[Herbert Greenlee] will Bee event display run on GPVM? (answer) not known, likely not
-
[Brian Rebel] data conversion is required each time, no possibility to rerun an algorithm on the fly
-
additional discussion on updating
SpacePoint data product is deferred to after the meeting
Conclusions
-
discussion is needed about progressing with the integration
-
LArSoft and DUNE will discuss the design of the new data product (or equivalent) for charged space points
Factorization of LArSoft core services [Jonathan Paley]
-
decoupling of services from data provider
-
allow future use of databases to retrieve service information (DUNE 35t might want to do that soon)
-
breaking changes:
-
TimeService is renamed to DetectorClocks; SimpleTimeService no longer exists
-
some detector specific stuff has been moved to
DetectorProperties
-
[Gianluca Petrillo] would like a map of what ened up where, to help users update their code
-
from service handles a constant pointer to service provider can be retrieved
-
[Marc Paterno] can call to
getDetectorProperties() return a null pointer? (answer) it shouldn't, but it might
-
art::ServiceHandle<>() use may be too much overhead when called in tight loops
-
a lot of instances found where:
-
header files are
#include'd for services that are not used
-
handles are instantiated for services that are never used
-
some clean up has already been done
-
the interface to retrieve the service provider is inconveniently complex
-
a few details left to be fixed
-
code review will be requested afterward
-
the code should not lie in feature branches too long, since updating it is a burden every time
Conclusion
-
need to define the matter of the interface, i.e. how to get the provider
-
code review will be requested after a few details left to be fixed
Showering algorithm [Mike Wallbank]
-
arises from the need for neutral pion reconstruction in DUNE 35t
-
reconstructs 3D showers from 2D cluster objects
-
performs all reconstruction in 2D
-
and then matches between views to form 3D
-
no changes to shower data products are required
-
ready to merge branch feature/wallbank_EMShowerToMerge although development going on
Conclusion
The feature branch will be included in the next release.
Update on LArLite and LArSoft integration [David Dagenhart]
-
purpose: integration: how to best share the code between LArLite and LArSoft
-
added a new LArLite data type, wrote and read it
-
using a prototype wrapper class to read/write LArLite product and allow the use of LArSoft product
-
some of the suggested actions might be:
-
refactor data product classes to reduce non-essential library dependencies
-
refactor LArSoft UPS products with minimal library dependencies
-
collected key differences between LArLite and art/LArSoft
-
considering whether a "art Lite" distribution might help the integration
Conclusions
-
this is preliminary work, and there is no proposal on the table yet
-
the task force will have meetings with LArSoft team and LArLite representatives to expand on some of the points
LArSoft Simulation Profiling [Hans Wenzel]
-
the scope: evaluate the use of Geant4 through LArSoft in the LArIAT simulation
-
recommended using Geant4 4.10.1 (patch 2)
-
test setup: lariat v01_07_00, geant v4_9_6_p04b
-
FHiCL configuration files from Johnny Hu (LArIAT)
-
[Chris Jones] which buffer size is used for ROOT IO? (answer) whatever is default (likely: 16 kiB)
-
highest cost in terms of CPU and memory: compressing and decompressing
-
fine space partition ("voxelization") puts a hard constraint on Geant
-
[William Seligman] removing the voxelization will come with additional code to do at least part of what was achieved with it, so the gain is not as straightforward
-
a list of recommendation and discussion points is provided
Some conclusions
-
Hans Wenzel will present to MicroBooNE's simulation group to collect ideas and discuss
-
all experiments should consider these points
There are minutes attached to this event.
Show them.