Present: Vito Di Benedetto, Krzysztof Genser, Herbert Greenlee, Thomas Junk, Katherine Lato, Marc Paterno, Gianluca Petrillo, Erica Snider, Jason Stock, Hans Wenzel
Remote: Diego Garcia-Gamez, Gleb Sinev, ...
Project status report [Erica Snider]
- proposing to adopt updated Genie (2.12.6) and GEANT4 (10.3)
- planning to move geometry service providers into
larcorealg
- [Thomas Junk] will changes in
CMakeLists.txt
files be necessary? [A] Yes, and they should be scriptable
- will provide scripts to help migration
- attendance on the workshop was good (more than 40 people)
- a lot of interest about multithreading
- git repository configuration changed so that pushes are slower due to per-push garbage collection operations, to reduce the size of the repositories and the
- [Thomas Junk] can we schedule an automatic periodic garbage collection instead, or a garbage collection every N pushes? [A] We don't know why the experts chose this solution...
Conclusions
- LArSoft will send a request via e-mail to elicit approval of Genie and GEANT4 update
Change to the Argon beta spectrum [Jason Stock]
- two corrections missing from current LArSoft, which make Argon beta spectrum harder
- relevant changes in detected activity (using DUNE settings)
- [Hans Wenzel] GEANT4 has nuclear decay models.
- [Thomas Junk] GENIE does not have Ar39 cross sections: adding that material in GDML description will cause problems
- [Jason Stock] this helps simulating other spectra (e.g. from concrete)
- corrected spectrum is significantly closer to the measurements
Conclusions
- the new spectrum will be merged as there is no objection
Using new GEANT4 features in LArG4
[Hans Wenzel]
- plans to
- replace physics list-related code with the one from GEANT4
- add hooks in FHiCL configuration to control GEANT4 parameters
- define a new intermediate data product
- in longer term
- define optical properties in GDML
- set the primary GDML source to be processed by GEANT4 into a ROOT-able one
Simulation of optical boundaries in LArSoft [Diego Garcia-Gamez]
- how it is set in
LArG4
, GEANT4 does not simulate light refraction (only reflection)
- refraction is important when dealing with wavelength shifting materials
- a bug was found in GEANT4 timing related to the wrong treatment of the first step of a photon
- patch can be applied afterward to
LArG4
- the correct way would be to have GEANT4 fix it upstream
- [Herbert Greenlee] isn't wavelength shifting a volume process (as opposed to a boundary one)?
- [Diego Garcia-Gamez] this failed when using the simple simulation in
LArG4
[Hans Wenzel] that's probably because not all material parameters are transmitted
- [Gianluca Petrillo] the configuration parameter might be better suited for
LArG4Parameters
service [A] no preference
- [Thomas Junk] is reflection diffuse or specular? [A] in simplified LArSoft model, it's either purely specular, or Lambertian
- [Thomas Junk] what happens when GEANT4 is fixed? [A] the patch in
LArG4
will become useless but still harmless
- [Thomas Junk] the patch code has an exact floating point comparison, that it might be better to replace with a tolerance
Conclusions
- Hans Wenzel is going to open a ticket against GEANT4
- the patch will be integrated in LArSoft
Source code documentation template [Erica Snider]
- objective: make code understandable to code users and maintainers, and to result users
- suggesting guidelines and a list
- [Herbert Greenlee] author institution and experiment should be added
- [Herbert Greenlee] the template should be available on a web page as well
Conclusion
- will produce templates and publish them
Discussion of handling floating point exceptions in LArSoft [Herbert Greenlee]
- floating point exceptions are ignored by default
- this has caused proliferation of overlooked invalid values in our data
- [Marc Paterno] art stakeholders agreed some time ago to remove the module-by-module granularity control because of overhead in multi-threading jobs
- [Herbert Greenlee] in D0, a campaign of production with floating point exceptions enabled was eventually successful
- [Marc Paterno] another campaign might be to verify that no
nan
ends in data products
- [Herbert Greenlee] proposes a campaign of eradication
- [Erica Snider] are the experiments willing to pay effort to fix these problems?
- [Erica Snider] a campaign against uninitialised variables was also successful in CDF
- [Herbert Greenlee] MicroBooNE might go through this enterprise; who would join?
- [Erica Snider] LArSoft has no effort to lead the campaign, but will support the campaign
Conclusions
- we need to figure out where we stand
- LArSoft community will attempt to start a campaign against floating point errors
There are minutes attached to this event.
Show them.