|
Present
|
Vito Di Benedetto, Giuseppe Cerati, Lynn Garren, Robert Hatcher, Alex Himmel, Kyle Knoepfel, Saba Sehrish, Hans Wenzel
|
|
Remote
|
Erin Conley, Katherine Lato, Ben Morgan, Paul Russo, Gleb Sinev
|
- Feature branch request: in larsim jsoto_maxrange_in_extendedphotlib
- Bug fix in progress: issue #21041 for BlurredClusteringAlg
-
Q: if the plan is to also look at the code that can be factorized to be able to migrate?
-
A: For the first pass, we are only looking at the code as it is but making a note of potential candidates after they have been refactored.
- The purpose is to upgarde LArSoft to use the new art release that also provides multi-threading
- To enable multithreading you have to opt for it, the default art behavior is still sequential
- [Kyle Knoepfel] and [Lynn Garren] have been working on this
- Some key points and observations
- art services are not the most well-defined constructs in art
- Do not use callbacks directly in your code, for services
- NuRandomService: upcoming change in the createEngine to return Art-owned reference to engine, so there is no need to interact with it directly
- There should be no header guards in the files that are not intended to be included
- art removed the ability to reconfigure modules several versions ago
- ThreadSanitizer is a useful tool for data race detection, and was used by [Paul Russo] while working on multi-threading art.
- Problem to address is that services must tbe configured in consistent ways across different art jobs.
- a potential solution is to have a wrapper script (that looks at fhicl configurations, runs config_dumper as needed).
- Conclusion: There was an agreement to have discussion(s) with the art and LArSoft experts to understand the requirements and possible solution proposal.
- It is important to identify whether service is what is needed for a particular problem, and may be there are different options that can pursued for each of different use of service.
There are minutes attached to this event.
Show them.