larsoft/larsim

This code is part of the Liquid Argon Software (LArSoft) project. It contains simulation and reconstruction algorithms for LAr TPC detectors. If you have a problem, please log a redmine issue: https://cdcvs.fnal.gov/redmine/projects/larsoft/issues/new

larsoft

This code is part of the Liquid Argon Software (LArSoft) project. It contains simulation and reconstruction algorithms for LAr TPC detectors. If you have a problem, please log a redmine issue: https://cdcvs.fnal.gov/redmine/projects/larsoft/issues/new

See the LArSoft wiki

larsoft is an umbrella product used to setup all larsoft products.

Dependencies

larsoft
|__larana
|  |__larreco
|     |__larsim
|     |  |__larg4
|     |  |  |__larevt
|     |  |  |  |__lardata
|     |  |  |  |  |__larcore
|     |  |  |  |  |  |__larcorealg
|     |  |  |  |  |     |__larcoreobj
|     |  |  |  |  |__lardataalg
|     |  |  |  |  |  |__lardataobj
|     |  |  |  |  |__larvecutils
|__lareventdisplay
|__larexamples
|__larpandora
|  |__larpandoracontent
|__larrecodnn
|__larsimdnn
|__larsimrad
|__larsoftobj
|__larwirecell

larsim's Issues

A kind request from the BxDecay0 team

Hi LArSofters,

Not really an issue but a kind request...
Would you agree if I put a reference to Dune and its LArSoft on the BxDecay0 main page ?
I plan to list a few projects (with logos) that use this lib within their MC tools.
Many thanks to welcome my request with good will. ;-)
Regards
frc

Origin "unset" in FilterGenInTime module

I've noticed whilst analysing a set of files simulated as "intime cosmics" using this module in the generation stage that the origin field becomes set as unknown, as does the generator information. This is because when the MCTruth is remade in this module the default constructor is used and then these fields are not updated.

It is complicated by the fact that this module has the capacity to narrow multiple MCTruths into 1, so deciding what to set for these values could be non-trivial. In the SBND case this module is used to convert 1 MCTruth into 2 (out of time and intime), as such both could easily have these fields set to the same value as the original.

It appears from some of the hardcoding (e.g. here) that this would be true for all uses of this module across any experiment but I can't be certain. One solution could be to set the Origin & GeneratorInfo only in the scenario where they are identical for all inputted MCTruths? This would cover the main (only?) use of this module but in theory protect against false information being filled for the narrowing case.

I hope this makes some sense, I would be interested in hearing opinions from @wesketchum @lgarren @knoepfel before I proceed.