use unweighted filter efficiency to calculate number of required input events
In !1289 (merged) I had the issue, that the commit script appears to use the "weighted filter efficiency" to compute the number or needed input events as opposed to the "unweighted" one. This is not correct, take the example (attached) of highly-weighted input events, where the filter is removing preferrentially high-weight events, thus we get Filter Efficiency = 0.570255 [10000 / 17536] Weighted Filter Efficiency = 0.014686 [26912615882800.000000 / 1832511495909600.000000] The relevant number to see if the job runs is the unweighted number, as this really tells us how many events need to pass.
Maybe a separate issue: it appears there is a blanket 10% safety applied. Note while I have not correctly calculated the right number, this can be both to little and too much and a safety of 4*sqrt[target output events]/[filter eff] would probably be better (this would be ~4sigma) Example 1: number of output events is 10000, so "4sigma" would be ~400 events, or just 4% Example 2: number of output events is 50, so "4sigma" would be ~14 events, or 14%