Store LHA ID of the original PDF set

[ktht]

The LHA ID of the PDF set stored in LHEScaleWeight branch does not necessarily correspond to the original PDF set that was used in the production of the sample. This can be problematic if an analyst wants to reweight to a different PDF set (which implies the knowledge of the original PDF set) that is not in the priority list or if the list is not kept up-to-date (as was the case with the pre-legacy NanoAOD Ntuples). Furthermore, it's also useful from the perspective of documenting and citing the correct sources.

One way to access the original LHA IDs is to do the following:

const lhef::HEPRUP &heprup = lheInfo->heprup();
const int original_lhaid = heprup.PDFSUP.first; // same as heprup.PDFSUP.second

And then update pdfDoc. It gives the correct LHA ID in 95% of the cases, but in some rare instances the stored value is simply -1. I think that it's a separate problem, though, that can be solved with GEN.

I can prepare a PR in the upstream if needed.

[ktht]

There's a mistake in my original post: in order to reweight to an alternative PDF set, it's not required that we know the original PDF that the sample was produced with if the LHEPdfWeight branch already stores weights for some other PDF set. This is because the nominal PDF weight (LHEPdfWeight[0]) is proportional to PDFs(other)/PDFs(original), so it's sufficient to know LHA ID of the PDF set for which there are weights available. The reweighting can be done by simply assigning LHEPdfWeight[0] * PDFs(alternative) / PDFs(other) to every event, where PDFs are computed with LHAPDF.

That said, I still think that storing this information somewhere in NanoAOD is useful for documentation purposes, especially given that the computational overhead is negligible.

[vlimant]

@kdlong is this in cms-sw#32167 too ?