genproductions
genproductions copied to clipboard
cms-sw
Backport powhegUL to master branch
Dear all,
This PR aims to introduce the b_bbar_4l process (work done by @lauridsj and @agrohsje) in genproductions so it can be used for Run3 bb4l production. I took cards and required patches from Laurids' PR: pull 3493.
One thing I did not modify is the PDF sets in the make_rwl.py script. So in principle this is using the default
PDF sets from Run3. I'm not sure if we want to reduce the amount of sets (to reduce computational costs) for
this particular case, since b_bb4l reweighting can be quite consuming.
I think other required patches are already merged in genproductions. In particular I'm refering to pull 3477, which seems to be already merged in master.
Thanks in advance, Carlos Vico
Hi @Cvico, thanks a lot for this! bb4l is quite slow, so we probably do want to reduce the PDF sets similarly to what was done in UL. There, I simply took the standard 102 replicas for the nominal PDF sets (NNPDF3.1) and then included only the nominal PDFs for alternative PDF sets. One could also go without any alternative PDF sets at all and only use the 102 variations.
Can I ask: did you try to compile Powheg in the master branch already? I remember that I had trouble with that on master, but it might be fixed by now.
Cheers, Laurids
Hi @Cvico, thanks a lot for this! bb4l is quite slow, so we probably do want to reduce the PDF sets similarly to what was done in UL. There, I simply took the standard 102 replicas for the nominal PDF sets (NNPDF3.1) and then included only the nominal PDFs for alternative PDF sets. One could also go without any alternative PDF sets at all and only use the 102 variations.
Can I ask: did you try to compile Powheg in the master branch already? I remember that I had trouble with that on master, but it might be fixed by now.
Cheers, Laurids
Hi Laurids, I'll have a look into PDFs then. I agree that it's better to reduce.
About compiling in master, I've been doing tests and I was able to include it within the master branch and compile, but only with CMSSW_10_6_X releases. I think the main problem is with the fortran version in CMSSW_12_X, but I think powheg gridpacks are agnostic to what release they were made in. Maybe @agrohsje can comment on this, I took this info from this thread in CMSTalk: https://cms-talk.web.cern.ch/t/hzz-failure-compiling-fortran-for-hzj-powheg-process/21259/4.
So other than checking that this compiles in 10_6_X, I've not done anything more.
Indeed, for the time being, we can run in the sl7 10_6 environment on el8 nodes. Our new Powheg contact is looking into fixing these problems. But he just started, so it might take some time.
