Fix issue where CRT HitTree in calibration tuples did not store run number. #860
Conversation
…r were left uninitialized.
…d added TriggerTimestamp variable to DAQTree.
aheggest
left a comment
aheggest
left a comment
There was a problem hiding this comment.
Looks good to me. Thanks @francescopoppi for addressing the bug and fixing the indentation for readability! I approve these changes
|
trigger build larsoft@v10_06_00_02 LArSoft/lar*@LARSOFT_SUITE_v10_06_00_02 SBNSoftware/sbnalg@v10_06_00_05 SBNSoftware/sbnobj@v10_01_01_01 SBNSoftware/sbnanaobj@v10_00_05_02 SBNSoftware/sbndaq_artdaq_core@v1_10_06 SBNSoftware/sbncode@v10_06_00_06 SBNSoftware/icarusutil@v10_06_00_04 SBNSoftware/icaruscode@v10_06_00_06p1 |
|
✔️ CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard |
|
✔️ CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard |
|
❌ CI build for ICARUS Failed at phase build ICARUS on slf7 for c14:prof -- details available through the CI dashboard 🚨 For more details about the failed phase, check the build ICARUS phase logs parent CI build details are available through the CI dashboard |
|
❌ CI build for ICARUS Failed at phase ci_tests ICARUS on slf7 for e26:prof - ignored warnings for build -- details available through the CI dashboard 🚨 For more details about the failed phase, check the ci_tests ICARUS phase logs parent CI build details are available through the CI dashboard |
This PR fixes a bug where due to the fact CRTData were dropped from Stage0, running Stage1 did not fill run number and sub run number. This caused the usage of uninitialized variables. This error was spotted thanks to @mt82 who did consistency checks between productions.
On a side note, I cleaned the code from some bad indentation that made the code unreadable.
I also added Trigger Timestamp to the DAQTree, it should have been there since the beginning.