AlphaS against latest master, including code generation and all processes generated

[valassi]

Hi @roiser I am creating here a PR superseding your #428 (to address the running of alphas issue #373). The main differences will be

• porting to the current latest upstream/master
• backporting your changes (in ggtt only for now) to code generation, and generating all five processes I use

[valassi]

I am making progress on integrating this, but there is work to be done.

I would say the main problems were:

• while check.exe and gcheck.exe were ok, both runTest and the fcheck test were failing 78c4ed3
• code generation was not there, and the design of the interface was using gc10/gc11 which are process-dependent parameters that should be removed from the interface (in eemumu they are not needed, for instance)

What I have done so far:

• I have removed gc10/gc11 from the bridge interfaces, and only kept gs (NB: gs are actually also not needed in some processes like eemumu as this is a QCD coupling, but the whole Madgraph machinery distinguishes between couplings that are dependent or not on alphas, so for the moment I would keep the gs as-is in the interfaces)
• gc10 and gc11 are now allocated within MEK, no longer within check_sa: they are an internal detail of MEK, they do not need to be exposed outside it
• there was no way to pass gs through fbridge.inc from fortran code, I have now added that
• partly thanks to the above, the fcheck tests are now succeding (amongst other things, the hardcoded value of gs that is set in check_sa.cc also needed to be set in fcheck_sa.f, and is now passed through fbridge.inc)
• I have removed the computeDependentCouplings method from the MEK and from the Bridge: given that only Gs (not gc10, gc11) are passed through the bridge interface, I aminclined to treat thecomputation of dependent couplings as one instance of 'splitting kernels'... I will cook up something for now (possibly moving it to calculate_wavefunction), eventually this should be reviewed together with splitting kernels
• I have started to rename and move the actual computation of dependent functions: I moved it to HelAmps for now, as it is a process-dependent computation (essentially it should only appear in HelAmps.h, or CPPProcess, or Parameters_sm: these are the only three files with process dependent stuff, all the rest I am trying to keep process independet)

Amongst the things tha are not yet ok

• runTest still fails
• remove gc10 and gc11 from sigmakin and similar interfaces, just keep g
• (minor reminder: copying Gs inside the bridge must be fixed if fptype is not FORTRANFPTYPE)
• (minor reminder: check timers in check_sa, find the right spot for copying gs)

[valassi]

Ok I have now

• fixed runtest (was missing hardcoding gs)
• fixed fptype!=FORTRANFPTYPE (and the fgcheck test in float mode now succeeds, it was failing)

Still t do amongst other things

• remove gc10 and gc11 from sigmakin and similar interfaces, just keep g (this is necessary for code generation)
• (minor reminder: check timers in check_sa, find the right spot for copying gs)

In addition

• investigate performance? I saw the number of registers has increased from 170 to 200 in ggtt double

[valassi]

I need to understand ho wto do gc10/gc11 with respect to code generation. I am dumping my main ideas in #356, as this is mainly about how to split the roles of MEK and CPPProcess (very much relatedto splitting kernels #310)

[valassi]

Some progress, I transformed BufferCouplings into a buffer that holds an arbvitrary number ndcoup of coupling arrays. It works so far. Now I need to change the access functions.

[roiser]

My idea here was to let the code generation do the work, but if you want to change this its also fine with me.

[valassi]

This is FINALLY completed

• code generation is complete
• both eemumu with fixed couplings and ggtt* with running couplings are handled in codegen (I have stripped off testing one process with both of them to Reminder: check code generation for a process with BOTH dependent and independent couplings #438)
• I have regenerated and tested all 5 processes and created a nice summary table
• WARNING! I have regenerated heft_gg_h and this generates ok, but it fails to build at runtime for the rather complex issue Fix heft generation after alphas PR: more fundamentally, remove reading of param_card.dat? #439... I will NOT fix this now, but I will merge this anyway as I think that SM physics for LHC takes priority over BeyondSM generations
• WARNING! I have regenerated uudd and this generates ok, but it fails to build with another issue Fix uudd in generation after the alphas merge #440. Hopefully this is rather simple. Anyway again I will merge this as is because this has been dragging on for far too long...
• WARNING! I have also regenerated eemumu.mad, ggtt.mad, ggtt.madonly. While ggtt.madonly builds fine as expected, the two .mad builds fail. This is expected, because I have not integrated the alphas from madevent into cudacpp. This will be one of the next priorities, Fix eemumu.mad generation and build after the alphas merge (integrate alphas and madevent) #441. I will merge this standalone cudacpp anyway.

[valassi]

Note the performance difference between pre and post alphas:
https://github.com/madgraph5/madgraph4gpu/blob/7d1a6d9b604578c0957ebbf566539d4fb6121aac/epochX/cudacpp/tput/summaryTable_alphas.txt

Example

-------------------------------------------------------------------------------

+++ cudacpp REVISION 88fe36d1 +++
On itscrd70.cern.ch [CPU: Intel(R) Xeon(R) Silver 4216 CPU] [GPU: 1x Tesla V100S-PCIE-32GB]:

[nvcc 11.6.124 (gcc 10.2.0)] 
HELINL=0 HRDCOD=0
                eemumu          ggtt         ggttg        ggttgg       ggttggg
         [2048/256/12]  [2048/256/1]  [2048/256/1]  [2048/256/1]    [64/256/1]
CUD/none      1.32e+09      1.42e+08      1.44e+07      5.13e+05      1.21e+04
         [2048/256/12]  [2048/256/1]    [64/256/1]    [64/256/1]     [1/256/1]
CPP/none      1.66e+06      2.00e+05      2.48e+04      1.80e+03      7.15e+01
CPP/sse4      3.09e+06      3.15e+05      4.50e+04      3.34e+03      1.30e+02
CPP/avx2      5.47e+06      5.69e+05      8.82e+04      6.79e+03      2.60e+02
CPP/512y      5.87e+06      6.12e+05      9.81e+04      7.46e+03      2.83e+02
CPP/512z      4.67e+06      3.85e+05      7.22e+04      6.56e+03      2.95e+02

+++ cudacpp REVISION bae5c248 +++
On itscrd70.cern.ch [CPU: Intel(R) Xeon(R) Silver 4216 CPU] [GPU: 1x Tesla V100S-PCIE-32GB]:

[nvcc 11.6.124 (gcc 10.2.0)] 
HELINL=0 HRDCOD=0
                eemumu          ggtt         ggttg        ggttgg       ggttggg
         [2048/256/12]  [2048/256/1]  [2048/256/1]  [2048/256/1]    [64/256/1]
CUD/none      1.10e+09      1.36e+08      1.17e+07      4.91e+05      1.11e+04
         [2048/256/12]  [2048/256/1]    [64/256/1]    [64/256/1]     [1/256/1]
CPP/none      1.65e+06      1.99e+05      2.46e+04      1.79e+03      7.21e+01
CPP/sse4      3.10e+06      3.13e+05      4.43e+04      3.33e+03      1.32e+02
CPP/avx2      5.35e+06      5.61e+05      8.80e+04      6.76e+03      2.61e+02
CPP/512y      5.96e+06      6.11e+05      9.91e+04      7.58e+03      2.91e+02
CPP/512z      4.60e+06      3.80e+05      7.15e+04      6.48e+03      2.93e+02

-------------------------------------------------------------------------------

There is almost no difference in cpp (as expected?). CUDA on GPU seems around 10% slower consistently. But I guess we need to live with that...

[valassi]

(Well, about performance: not sure at all why eemumu would be slower... I opened #442 to investigate further if someone has the courage).

This is now complete. I am self merging.