Bug #18723

Inconsistent information in GENIE MCTruth record

Added by Gianluca Petrillo about 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:
Occurs In:


GENIE generates its event in the origin of its universe, around (0;0;0).
The helper in nutools translates the generated particles (simb::MCParticle) in the correct place of the detector... but:
  1. it does that only on the trajectory of the particles, not on the "generated vertex": in each particle, they are inconsistent
  2. it does that only on particles with status 1: positions of the different particles in the truth record are inconsistent
There are two options:
  1. fix point (2) only: all trajectories get consistent, but the generator vertex still points to the place where GENIE originally generated the particle
  2. fix both points: generated vertices will lose the connection with the original generation location but will gain consistency with the particle position
There are also two possible strategies:
  1. ask nutools to fix that on GenieHelper for everybody
  2. have LArSoft GENIEGen module post-process the output from GenieHelper and apply a patch

The latter strategy might be the precursor of the former.


#1 Updated by Robert Hatcher about 3 years 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.

#2 Updated by Lynn Garren almost 3 years ago

  • Status changed from New to Accepted

Gianluca and Robert will talk.

#3 Updated by Gianluca Petrillo almost 3 years 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 $\mathcal{O}\left(10^{-15}\,\textnormal{m}\
ight)$, 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.

Also available in: Atom PDF