Backport powhegUL to master branch

[Cvico]

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

[lauridsj]

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

[Cvico]

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.

[agrohsje]

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.

[Cvico]

Hi, I've updated the PR with the PDF configs from Run2 UL gridpacks

[covarell]

Can we merge this PR, now?

[lviliani]

This is quite old but I think we can merge, right? We should resolve the conflict in runGetSource_template.sh first, though.

[agrohsje]

Dear @bbilin @lviliani @Cvico @lauridsj @sihyunjeon @DickyChant . This PR is a core PR to run bb4l in cms. It is more than 1 year old. If we don't merge such PRs in a timely manner we are screwed. Who is now in charge to judge this PR and fix it?

[lauridsj]

Hi, from what I can see in the code it looks fine. I never tested it in the master branch, but I think @Cvico did, so it should be fine to merge. If you want to be sure, someone could test compiling bb4l with this branch.

[Cvico]

Hi, I did get it to work 1 year ago. Just for sanity check, I can try to see if it still works in EL8 (this was done back when we had CC7 on lxplus). If that works, I would just remake the PR... Although I don't have an strong opinion there.

Which CMSSW version should I use? I understand current production is based on el8, so a 13_3_X should do the trick. But I'm not sure if my understanding is correct. This is relevant in powheg processes because fortran compilation is often quite annoying (I did a small try on 13_3_X right now and I get a fortran compilation error in openloops because types cannot be initialized in the same way for newer fotran versions). This can be fixed but it's better if we can settle on which version.

[covarell]

Hello, to get this to work in el8, you also need #3716 which is also NOT merged after many months @jshin96 .
Indeed, I totally agree with @agrohsje: leaving core POWHEG PRs unattended for a long time can generate a lot of these conflicts.

[Cvico]

I can redo the PR once this #3716 is accepted. I don't mind redoing, and we can make sure time it gets merged promptly. By the way, just to mention that (for this particular PR ) I'm of course also partly to blame of course, I made the PR and forgot about the status because it got obscured by many other things. Very busy schedules in GEN related stuff!

For sake of proactivity let's put things in order and I can remake the PR. This time I'll put extra effort on making sure we get it merged in a timely manner as @agrohsje suggests :D

[bbilin]

As it was written by Carlos, this summer it was busy with many other activities, including the production of this very bb4l samples.. So in the end we were using the setup without getting it merged into the genproductions.

In general we need to define a better review policy for MG, Powheg, Sherpa or other generators, involving the generator contacts in a more active way and NOT waiting for two L2 conveners following EVERYTHING.

[covarell]

Can we close this PR, please? @Cvico please redo the PR ONLY WHEN #3795 is also approved, otherwise b_bbar_4l does not work at all