Generator weights
The standard way to use generator weights is to take GenEventInfoProduct::weight()
as the nominal weight and rescale all alternative LHE weights by the ratio between that weight and LHEEventProduct::originalXWGTUP()
. Here is a real-life example. We should switch to this procedure after the migration to NanoAOD.
Currently the weights are applied differently. In some places EvtWeights[0]
is used, while in others it is EvtWeights[1]
. They correspond, respectively, to GenEventInfoProduct::weight()
and LHEEventProduct::weights()[0].wgt
. The last weight is the trivial scale variation μR = μF = 1; normally, it is supposed to be equivalent to LHEEventProduct::originalXWGTUP()
.
To emulate the standard procedure, use EvtWeights[0]
as the nominal weight and rescale all other weights by EvtWeights[0] / EvtWeights[1]
. Implement an interface to access the weights and encapsulate the rescaling behind it. Also provide a semantic access to the alternative weights instead of forcing the caller to rely on raw indices.
There are two problems:
- In some data sets, at least in the HT-binned γ+jets ones,
EvtWeights[1]
changes between events. However, this weight seems to be constant in consecutive blocks of events. This must be because MadGraph has been configured to use the calculated cross section as the numeric value of the weight, and the cross section was slightly different in different jobs producing LHE events. The work-around above will eliminate these fluctuations. - Something strange is happening with the POWHEG + JHUGen VBF H→ZZ→2ℓ2ν samples. The result of
GenEventInfoProduct::weight()
, which is equal toLHEEventProduct::originalXWGTUP()
, changes between consecutive events. At the same timeLHEEventProduct::weights()[0].wgt
is constant. It is not clear which weight should be applied and if the samples are usable at all. Adopting the procedure above will change the results for these samples.