Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Off by one issue in InteractionNumber #61

Open
jdkio opened this issue Oct 8, 2024 · 2 comments
Open

Off by one issue in InteractionNumber #61

jdkio opened this issue Oct 8, 2024 · 2 comments
Assignees

Comments

@jdkio
Copy link

jdkio commented Oct 8, 2024

The interaction numbers start at -1 instead of 0. This is in the file new mircoprod files. Specifically:
/pnfs/dune/persistent/users/abooth/nd-production/MicroProdN1p2/output/run-spill-build/MicroProdN1p2_NDLAr_1E18_RHC.spill.nu/EDEPSIM_SPILLS/0000000/0000100/MicroProdN1p2_NDLAr_1E18_RHC.spill.nu.0000102.EDEPSIM_SPILLS.root

root [1] EDepSimEvents->Scan("InteractionNumber")
***********************************
*    Row   * Instance * Interacti *
***********************************
*        0 *        0 *        -1 *
*        1 *        0 *         0 *
*        2 *        0 *         1 *
*        3 *        0 *         2 *
*        4 *        0 *         3 *
*        5 *        0 *         4 *
*        6 *        0 *         5 *
*        7 *        0 *         6 *
*        8 *        0 *         7 *
*        9 *        0 *         8 *
*       10 *        0 *         9 *

The interaction numbers were fixed in issue #54, but it seems like they're off by one now for some reason. Not sure why.

Actually, this sample is without rock files. So it's not the spill builder. Here's the same file pre-spill builder. Not sure why but it starts at -1

Attaching file /pnfs/dune/persistent/users/abooth/nd-production/MicroProdN1p2/output/run-edep-sim/MicroProdN1p2_NDLAr_1E18_RHC.edep.nu/EDE
PSIM/0000000/0000100/MicroProdN1p2_NDLAr_1E18_RHC.edep.nu.0000102.EDEPSIM.root as _file0...
(TFile *) 0x3df4840
root [1] EDepSimEvents->Scan("InteractionNumber")
***********************************
*    Row   * Instance * Interacti *
***********************************
*        0 *        0 *        -1 *
*        1 *        0 *         0 *
*        2 *        0 *         1 *
*        3 *        0 *         2 *
*        4 *        0 *         3 *
*        5 *        0 *         4 *
*        6 *        0 *         5 *
@jdkio
Copy link
Author

jdkio commented Oct 8, 2024

I tried some edep sim files that were made using ProcessND.py and they seem to be correct.

root -l /pnfs/dune/persistent/users/kleykamp/nd_production/2024-05-13_lar_only_rhc/edep/RHC/00m/00/antineutrino.0_1715654453.edep.root 
EDepSimEvents->Scan("InteractionNumber")
***********************************
*    Row   * Instance * Interacti *
***********************************
*        0 *        0 *         0 *
*        1 *        0 *         1 *
*        2 *        0 *         2 *
*        3 *        0 *         3 *
*        4 *        0 *         4 *
root -l /pnfs/dune/persistent/users/kleykamp/example_edep_file_with_overlay.root
EDepSimEvents->Scan("InteractionNumber")
***********************************
*    Row   * Instance * Interacti *
***********************************
*        0 *        0 *         0 *
*        0 *        1 *         1 *
*        0 *        2 *         2 *
*        0 *        3 *         3 *

Note that I've worked out a workaround for TMS

@mjkramer
Copy link
Member

My current hypothesis is that this results from the interaction of:

Specifically, the writing of the GENIE pass-thru entry previously happened early in the event loop, whereas now it happens near the end (so that the interaction can be omitted from the pass-thru tree if it turned out to be invisible). KinemPassThru::LastEntryNumber assumes the pass-thru entry has already been written, but now that's not the case. So line 254 should be changed from

    return fPersistentTree->GetEntries() - 1;

to

    return fPersistentTree->GetEntries();

I looked at an older 2x2 sim file and the first InteractionNumber was indeed -1, so this is not a new issue, just something we hadn't noticed since we weren't using the InteractionNumber anywhere. And this only affects files that haven't gone through spill building, since the original edep-sim InteractionNumber is now thrown away during spill building, as discussed in #54.

I'll test this change to confirm that it fixes the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants