GEANT4.10.04p2 Issue

[cnatzke]

The Issue I have compiled the geant4.10.04 branch of the detector simulations and run the basic 60Co example given in the example_simulations directory (with the two custom data file lines commented out) and tried to run the output through NTuple2EventTree. When I do so I get the error:

terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 16) >= this->size() (which is 16)
Aborted (core dumped)

The simulation was build against the latest version of geant4.10.04p2, GRSISORT, ROOT, CommandLineInterface, and NTuple2EventTree.

I have not changed any of the code in the simulations save for the branch via

git checkout geant4.10.04

What's been tried

• Another user on our machine tried to install and run the sims but ran into the same error.
• Tested NTuple2EventTree with an old .root file (NTuple2EventTree ran fine)
• I compiled a clean install of the simulation and all ancillary programs
• Ran a backtrace via gdb and received this output

  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
  #1  0x00007fffefe7a801 in __GI_abort () at abort.c:79
  #2  0x00007ffff04cf8fb in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #3  0x00007ffff04d5d3a in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #4  0x00007ffff04d5d95 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #5  0x00007ffff04d5fe8 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #6  0x00007ffff04d18c1 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #7  0x000055555555f4fb in std::vector<std::vector<TF1, std::allocator<TF1> >, std::allocator<std::vector<TF1, std::allocator<TF1> > > >::_M_range_check (__n=16, this=<optimized out>)
  at /usr/include/c++/7/bits/stl_vector.h:825
  #8  std::vector<std::vector<TF1, std::allocator<TF1> >, std::allocator<std::vector<TF1, std::allocator<TF1> > > >::at (__n=16, this=<optimized out>) at /usr/include/c++/7/bits/stl_vector.h:846
  #9  Settings::Resolution (en=<optimized out>, crystalID=<optimized out>, detectorID=<optimized out>, systemID=<optimized out>, this=<optimized out>) at Settings.hh:39
  #10 Converter::Run (this=0x7fffffffd030) at Converter.cc:211
  #11 0x0000555555558d04 in main (argc=<optimized out>, argv=<optimized out>) at NTuple2EventTree.cc:53

  Any help you guys can offer would be great!

[r3dunlop]

Does any part of this help? https://github.com/GRIFFINCollaboration/detectorSimulations_v10/issues/55

[VinzenzBildstein]

It seems like you're trying to access the resolution for a detector that doesn't exist, namely detector 16 (counting from 0) of 16. Can you try changing line 38 to if(fResolution.find(systemID) != fResolution.end() && detectorID < fResolution[systemID].size() && crystalID < fResolution[systemID].at(detectorID).size()) { and see if that solves the problem?

[cnatzke]

Line 38 in which file? EDIT: Settings.hh, found it

[cnatzke]

@VinzenzBildstein That seemed to fix it. I also had to change the fThreshold, fThresholdWidth, and fTimeWidth if statements to a similar form. I haven't checked the veracity of the sorting yet but I will update when I know.

@r3dunlop That seems to be the exact issue I was having. Any idea why it was occurring in the example macro?

[VinzenzBildstein]

@cnatzke, that's good, but check this only fixes the crash, not the underlying issue. I will simply return a resolution of zero for detector IDs or crystal IDs that are out of range. This might actually be an issue of detector IDs now being set to 1-16 instead of 0-15. To check that, can you make a plot of the detector ID and system ID? Just open the output file of the simulation (g4out.root) and use something like ntuple->Draw("detNumber","systemID<2000") that should draw the detector number for all events from GRIFFIN.

Actually, I just looked into the DetectorConstruction.cc file and the detector and crystal numbers for griffin (after being parsed from the volume name) are both incremented with the comment "start from 1 instead of 0". I'm not 100% sure why I did this, looking at SCEPTAR, it seem to also count from 1. But most of the other detectors use the imprint number as detector number and I think that one starts from 0. So maybe we should just remove the lines that increment the GRIFFIN detectors and change the SCEPTAR numbering to also start from 0.

I just made those changes, I will create the pull request for it in a second. @cnatzke, could you please test the output of the updated simulation with the un-modified NTuple2EventTree?

[cnatzke]

That seems to have fixed it. NTuple2EventTree had no issues and the gamma singles spectrum looks fine. Thanks for taking a look at this!

[VinzenzBildstein]

No, thank you @cnatzke for testing the new version. This is the best way to find bugs and hopefully soon we'll be able to merge that branch back into the master.