Check that Fortran results are the same with and without vector interfaces

[valassi]

Around the time of the release (not a blocker technically, but necessary for physics validation), we should check that Fortran results are the same with and without vector interfaces.

I think Olivier is already making a lot of tests in this direction. But just opening this as an explicit issue as a reminder...

cc @oliviermattelaer @roiser

[oliviermattelaer]

So investigation was wrongly reported to #630:
In short three bugs have been fixed, and one is currently pending

• issue with ipsel (selected diagram) (mg5amcnlo/mg5amcnlo@d668082)
• issue with the writting of the lhef file (mg5amcnlo/mg5amcnlo@8d099ef)
• issue with the reference scale that was always the same in the blackbox: ( mg5amcnlo/mg5amcnlo@97e1488)
• issue discover with chcluster=T
  • "scale" information is not correctly vectorised (mg5amcnlo/mg5amcnlo@ecf424f)
  • "scale" information is not correctly written in LHEF file (mg5amcnlo/mg5amcnlo@f98ca25)

[valassi]

Thanks Olivier :-)

Ok so for at least one (or more) of the issues that you just fixed, I am making tests in MR #703 of the madgraph4gpu machinery, I upgraded codegen to your latest changes. I will merge when all tests are ok

[oliviermattelaer]

Issue with chcluster

program that reproduce the issue:

define p = p / g
add process u g > t t~ j
output PROC_TEST --vector_size=8
launch
set nevents 500k
set ickkw 1
set mc_grouped_subproc F
set pdfwgt T
set chcluster T # Note this is the problematic parameter that impacts the black box.

This is the result that I expect:

46.27 +- 0.02233 pb (correct value from 3.5.0)
This is the result that I got:
46.13 +- 0.02268 pb(vecsize=64) [4 sigma away]
46.15 +- 0.02265 pb (vecsize=8) [3 sigma away]
46.22 +- 0.02365 p (vecsize=2) [1 sigma away]
46.26 +- 0.02338 pb (vecsize=1) [perfect]

The "problematic" lines are l466 SubProcesses/cluster.f
if(chcluster)then
if(id_cl(iproc,idij,i).ne.iconfig) cycle
endif

And the problematic channel is here G4 (all other channel are just perfect spot on).
Note that

• G4 does not have any symmetric channel, so iconfig is always 4
• The above setup has only one matrix-element (so iproc=1)

Since the above line are part of the findmt function, I have check that the spectrum of output given by that function are the same in 3.x and this branch. However, I have noted that this function is call less often in the new branch. I do not worry about that (at least for the moment).

More investigations:

• the as_ref is correctly handle here
• difference independent of the pdf re-weighting on T/F
  • one origin is the alphas reweighting and another (related) is the pdf re-weighting (smaller impact)
• q2now is not the same in both implementation -> so issue
  • q2now is sometimes set to pt2ij -> seems ok
  • q2now is sometimes set to "scale" -> seems not vectorised correctly
    • full remove of "scale" fix the issue (only tested for as reweighting here)
    • scale is used within sys_fact information

[oliviermattelaer]

Information for the computation of scale uncertainty should be correctly store/written now.
I have open #708 to follow up in that direction and be sure that the writting of the event is correct in all cases

[valassi]

Hi @oliviermattelaer thanks.
I reopen and assign to myself - this is a reminder that I need to move madgraph4gpu to your latest
mg5amcnlo/mg5amcnlo@f98ca25
Andrea

[oliviermattelaer]

Hi re-open it for me (even if you did not reclose it --you should have right--
Just to report here the latest issue with pp > t t~ process giving wrong cross-section
(and copy-paste the findings put on the hackathon document):

• Check Fortran cross-section WITH second exporter (fortran mode) **Failed (1261 pb) **
  • already issue for p p > t t~ (473.6 versus correct answer 505.8)
  • for g g > t t~ (correct answer 442.1)
  • for q q > t t~ (32.06 correct answer 64.17)
    • q q > t t~ has only 4 subprocesses within uu~ instead of the 8 expected (related to beam symmetry)
    • file processes.dat does not have the mirror included (so problem is at generation time)