Event Mixing code has incorrect behavior when nSecondaries returns 0
In a common mode of operation, we choose the number of background events to mix into the current event by drawing a random variate from a Poisson distribution. This number is chosen by the nSecondaries() method of the mix detail class. When this method returns 0, the mixing template does the following:
1. The processEventIDs method of the mix detail class is correctly called with an input argument that has a length of 0.
2. All of the user registered mixOp methods are called with a stale input argument; the input argument points to the data from the previous event!
So there are two issues. First, the input argument to the mixOp methods should be a vector of length 0, not a stale vector. The subset of the data that I looked at appears to be an intact copy of the data from the previous event; I understand that this can be an accident but it seems prudent to make sure that the memory is not leaked.
I have added a stripped down mixing module to illustrate the problem
and an fcl file to run it:
If you want to try this on oink you will have to copy the input event-data file.
I have worked around this by saving the value of nSecondaries in member datum and just returning from mixOp methods that should never have been called. We should still fix this.
- Category set to Navigation
- Status changed from New to Assigned
- Assignee set to Christopher Green
- Target version set to 0.07.16
The errant behavior has been observed in mu2e code; I will produce a test case and work on a fix for the 0.07.16 release.
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
The issue was an unwanted protection around the per-event
resize() of the container of incoming collections to be merged.
Fixed with d25d5de.
- Subject changed from Event Mixing code has incorrect behaving when nSecondaries returns 0 to Event Mixing code has incorrect behavior when nSecondaries returns 0
- Status changed from Resolved to Closed
Also available in: Atom