In the CAF files, there’s a significant number of truth-level primary particles (mc.nu.prim) with start and/or end positions populated as NANs. Looking into how the truth branches (mu.nu etc. etc.) are saved vs. the branches of truth-matched particles (common.ixn.dlp.truth etc. etc.), we see in this section of code that the start position for primary particles is never natively filled because the coordinates from GENIE need to be transformed to detector coordinates, which hasn’t been done yet. There is no mention of the end position branch, so I assume that is not filled either (this would need to come from edep-sim trajectory information).
On the other hand, the start and end position of truth-matched particles are filled here using ML Reco info, where it seems to check if the branches are filled with anything other than the default value (NaN) and either validate the existing non-NaN or replace it with the ML Reco truth info. I’m assuming that these truth-matched branches point back to the actual true branches (mc.nu), which, as described above, seems to not save start and end position. Therefore, any filled mc.nu.prim.part.start_pos/end_pos branches would only be filled due to truth matching done in ML Reco when the reco branches are filled.
noeroy
commented
1 month ago
In the CAF files, there’s a significant number of truth-level primary particles (mc.nu.prim) with start and/or end positions populated as NANs. Looking into how the truth branches (mu.nu etc. etc.) are saved vs. the branches of truth-matched particles (common.ixn.dlp.truth etc. etc.), we see in this section of code that the start position for primary particles is never natively filled because the coordinates from GENIE need to be transformed to detector coordinates, which hasn’t been done yet. There is no mention of the end position branch, so I assume that is not filled either (this would need to come from edep-sim trajectory information). On the other hand, the start and end position of truth-matched particles are filled here using ML Reco info, where it seems to check if the branches are filled with anything other than the default value (NaN) and either validate the existing non-NaN or replace it with the ML Reco truth info. I’m assuming that these truth-matched branches point back to the actual true branches (mc.nu), which, as described above, seems to not save start and end position. Therefore, any filled mc.nu.prim.part.start_pos/end_pos branches would only be filled due to truth matching done in ML Reco when the reco branches are filled.