Minutes for LArSoft coordination meeting on July 31, 2018

Present	Bruce Baller, Vito Di Benedetto, Giuseppe Cerati, Patrick Gartung, Krzysztof Genser, Alex Himmel, Tom Junk, Erica Snider, Saba Sehrish, Paul Russo, Hans Wenzel, Tingjun Yang
Remote	Chris Backhouse, Erin Conley, Katherine Lato, Gianluca Petrillo, Gleb Sinev, Brett Viren, Tracy Usher

Project status report [Erica Snider]

This weeks release, v07_00_00
- the first release with LArG4 re-factoring but partially working and first release with e17 support
larg4, new repository with only interface to geant
update on fixing the large size of larsim repo
- solutoins were discussed at the last LCM
- We have now a mechanism in place to check the a file before it is pushed in to the repository
- Plan to change the name of larsim -> lardetsim, schedule TBD

LArSoft license

Decision: proceed with Apache v2 license
Need to select copyright holder: Fermilab, other institutes?
Can LArSoft collaboration copyright it? No, it is not a legal entity to hold that.
Do we have to follow a process if we bring the code from some other project?
If some code is under GPL, we dont include that but for others we just follow the requirements by these licenses.
There is currently no specified timeline for that license
Tom noted that in GArSoft, lots of files had Brian Rebel as copyright holder
- He took out those lines
- This is exactly what we are trying to avoid, having individuals claim copyright of our code. Not appropriate for LArSoft since we collaborate to share code
Will people need to include license text in every file?
- Recommended, but not necessary if we include a prominently named file in each repository (the LICENSE file) that is legally sufficient
Note that other people will be able to re-distribute LArSoft under a different license
- We discussed this, but should be ok since our code base will still be protected by our license.
- The purpose is to protect our code so that others dont claim on our code

Conclusions

If there are comments on licence file, etc please send comments to larsoft team

========================================================================================================================================== Tracy Usher requested for a new feature branch merge, please email to the larsoft team.

LArG4 refactoring status and plan [Hans Wenzel]

the idea is to separate simulation from detector response
this is based on artg4 extended to include modern physics list factory and use of gdml by Robert Hatcher
[Alex Himmel] DUNE manually turns on physics lists. Does this interfere?
- Yes
Are these scriptable changes?
- It depends, and not easily scripted in most cases. For the specific case of physics lists, cant say yet, need to look at it.
Can we read in multiple gdml files in a single job?
- No
Alex wants to preserve having certain properties accessible via fhicl. Eg, the Rayleigh scattering length. In the new design, this is in the gdml. Hans suggested having a boilerplate gdml include file that contains common properties for LAr, for instance. Everyone could share this. [After the meeting, it was suggested that we simply use fcl parameters to override various parameters in the geometry, if necessary. This should be possible for things like the Rayleigh scattering length]
Alex pointed out the need for SimPhotonsLite
Paul suggested it is an easy fix. We are aware that it needs to go in
DUNE does not want to change infrastructure until after the TDR, which is next summer

Conclusions

refactored code is in v07_00_00, and currently does not interfere with the existing set up. Once complete, users will be requested to start using the refactored version of larg4, but there is no timeline for that yet.

TrajCluster update [Tingjun Yang]

Introduced new data product â€œrecob::Sliceâ€, to solve the problem of associating PFParticles to PFParticles
Art does not allow Assns between same object type
Use DBScan algorithm
if using code from a third party, follow their coding license process
Need to discuss whether this concept / data product can be extended to the other algorithms. Seem possible given that both Pandora and WC have similar concepts

Conclusions

There are following feature branches to be merged

larreco: feature/bb_restruct
lardataobj: feature/bb_recobslice
lareventdisplay: feature/bb_clsIDs