Inconsistent information in GENIE MCTruth record
The helper in nutools translates the generated particles (
simb::MCParticle) in the correct place of the detector... but:
- it does that only on the trajectory of the particles, not on the "generated vertex": in each particle, they are inconsistent
- it does that only on particles with status
1: positions of the different particles in the truth record are inconsistent
- fix point (2) only: all trajectories get consistent, but the generator vertex still points to the place where GENIE originally generated the particle
- fix both points: generated vertices will lose the connection with the original generation location but will gain consistency with the particle position
- ask nutools to fix that on
- have LArSoft
GENIEGenmodule post-process the output from
GenieHelperand apply a patch
The latter strategy might be the precursor of the former.
#1 Updated by Robert Hatcher over 1 year ago
Let's talk about this so I fully understand the concern and the exact variables in question.
There are important reasons not to adjust all the points to the detector coordinates -- this has to do with reconstituting the original GENIE event record for reweighing purposes. The original GENIE event record records everything relative to the center of the struck nucleus with displacements in femtometers (1e-15 meters). It keeps a separate single "vertex" in detector coordinates (meters). Adding these together and then subtracting off the "vertex" to recover the in nucleus displacements is a recipe for disappointment.
#3 Updated by Gianluca Petrillo over 1 year ago
- Assignee set to Robert Hatcher
Gianluca Petrillo and Robert Hatcher talked about the issue.
The position of the particle in the event frame as defined by the generator may be relevant for event reweighting in GENIE. That is mainly due to the fact that the position is stored in
double precision, the event size is , and the position in a detector is measured in meters. That means that the data type has not enough precision to preserve the femtometer details when storing meters.
Since for downstream processing some particles must be set into detector coordinates, it was chosen to translate only those ones (in particular, only the ones with
StatusCode() 1), and these ones are not used for reweighting.
After some time, new data members were introduced, in the form of a "generator vertex" (
Gvtx()) stored in
simb::MCParticle. With that, the need to preserve the
simb::MCParticle trajectory point in the generator frame drops and the trajectory can be translated into detector coordinates for all the particles at no loss.
This kind of change in data product will be breaking, in the worst way: old code may give wrong results.
Reweighting code is somehow centralised (or at least the intention and attempt was for that to be the model), which would make a update campaign more plausible.
The update consists of replacing the use of the first point of the trajectory with the use of the generator vertex.
The code change to have all the particles translated is trivial.
The event reweighting code change will likely also not be complex, the hardest part being to identify where the code is using the trajectory information (if anywhere: it might be already using the vertex).
Since that code is owned by Robert (or close to that), this ticket gets now assigned to him.