Custom Query (2425 matches)

After some discussion in #simulation (see ​https://icecube-spno.slack.com/archives/C02KQLBNU/p1601472749001700 ff), it seems that there are a number of modules that assume that input MCPESeries are time ordered. While this is typically true for standard output obtained from clsim/ppc, this might break if users modify the MCPESeries (e.g. by merging events). Modules that depend on time ordering should therefor either check that the MPCE are time ordered (and fail if they are not) or always sort the MCPE.

In some rare cases PROPOSAL puts Hadrons with a negative energy in the I3MCTree:

2130621 Hadrons (133.192m, 785.657m, 221.306m) (86.3862deg, 14.519deg) 92927.7ns -2.84217e-14GeV 0m

PROPOSAL doesn't throw an error, but CLSim complains when trying to get any photons out of these hadrons propagated.

A file containing the I3MCTree in question (including the preMuonProp tree and the RNG state) can be found in /data/user/eganster/shared/PROPOSAL/BuggyEvent.i3.zst

Running the detector simulation (simprod-scripts/resources/scripts/detector.py) from the latest combo release (V01-00-00 crashes with a segmentation violation. Most frequent, this error occurs for higher energy events (>100 TeV). This currently prevents us from running/producing simulations/MC with that combo release.

The stack trace (attachement) leads to an issue in I3DOMLauncher, possible connected to its recent changes for fixing the SLC timing offset of 25ns.

Chris Weaver already took a look at it and managed to track the underlaying issue down to:

Assertion failed: (index>0 && index<nFADCCoarseChargeStampBins), function MakeCoarseChargeStamp, file /Users/christopher/Work/IceCube/combo/src/DOMLauncher/private/DOMLauncher/I3InIceDOM.cxx, line 166.

A minimum "working" example can be found in /data/user/eganster/shared/Segfault_DOMLauncher