Fix PSWeight being incorrectly scaled

[jrueb]

PR description:

Use the 'Baseline' weight as nominal for parton shower weights. This ensures the correct scaling independent from the weighting strategy used for the dataset. Fixes #381

[arizzi]

I would say if you want to do it as a correction wrt nominal weight, it should be divided by weights[0] isn't it?

[jrueb]

Sorry, took my time to type this.

After a discussion with @agrohsje I reached the conclusion that the correct approach is to divide by the element at index 1 of the generator weights array. To summarize what is going on (similar to what @agrohsje already explained in #381): Depending on a configuration value of Pythia (the weighting strategy) the vector with generator weights (GenEventInfoProduct::weights) might either have the format

[XWGTUP * PSweight * match_eff, XWGTUP * PSweight, XWGTUP * PSvar1, ...]

or

[PSweight * match_eff, PSweight, PSvar1, ...]

Here PSweight is the nominal weight (computed from showering) and match_eff is a matching efficiency that is in most cases, but not all, 1.

This means that if we divide by XWGTUP but are in latter case, we incorrectly scale the parton shower weights. Similarly, we don't want to divide by match_eff, as it isn't multiplied to the variations (the later elements of the vector)

[arizzi]

thanks for the clarification

[jrueb]

It has no impact to this PR, but please note that I'm not completely sure about the definition of originalXWGTUP. What I call XWGTUP in above comment is the factor Pythia multiplies due to the weighting strategy and might not completely agree with the value of originalXWGTUP.

[gpetruc-bot]

Automatic test started, see https://gitlab.cern.ch/cms-nanoAOD/nanoAOD-integration/pipelines/1482409/builds

[gpetruc-bot]

Automatic code format failed (run scram b code-format to fix)

[gpetruc-bot]

Automatic test started, see https://gitlab.cern.ch/cms-nanoAOD/nanoAOD-integration/pipelines/1482575/builds