Virtual Packet Cutoff during Montecarlo

[yeganer]

In the montecarlo simulation there's a cutoff for virtual packets which boils down to:

if tau>10:
    tau == 100

This removes the contribution of weakly contributing packets almost completely (exp(-100) ~ 1e-44).
But because this isn't exactly 0 the packet will still register and add to the bin. If the packet is the only packet in that bin the resulting luminosity will be very small and numerical problems can surface when comparing different bins.

The solution I propose is to either set the weight or the energy of the packet to 0. This removes any contribution and even allows small performance improvements by skipping the spectrum update(which needs to be atomic)

[unoebauer]

Do we still need this? I agree conceptually with you that setting the weight or energy of the packet to 0 is the cleaner approach to discard virtual packets. However, I am wondering about cases where fluctuations in these parts of the spectrum ever become relevant.

[yeganer]

The current implementation creates three possible 'states' for a bin. It's either zero meaning no packet at all, ~1e-100 meaning only discarded packets registered for the bin or it has an actual value.
The first two cases should be the same and currently one needs to have a cutoff to separate these.

There are two cases where this issue was relevant in the past.

1. It makes comparing of the non-zero parts of spectra more difficult
2. Fred had to differentiate between the two types of packets when doing his statistical analysis for the virtual packets. If I remember correctly ~80% of the packets were discarded packets. One could skip logging these packets reducing memory consumption on the way.

As the fix is easy, quick and has no bad side effects that I know of the important question that needs to be answered should be "Why shouldn't we merge this?" instead of "Why should we merge this?"

[unoebauer]

Fine - I'd be in favour of merging.

[unoebauer]

Will be dealt with once the testing framework is fully operational

[unoebauer]

@wkerzendorf, @yeganer - thoughts on this? Should we merge this. Will require an update of reference data.

[chvogl]

Solved with merge of #911 .