Madgraph5 GPU development
Virtual (Zoom)
# Madgraph meeting Mon 10.01.2022
Present: SR, OM, SH, AV (notes), LF, TC, WH, CV, NN (later)
## Round table
### SH
ntr
### LF
ntr
### OM
OM: before the break, moved forward on MadEvent interface
Can have BOTH Fortran and C++ matrix elements at the same time
Would like to converge with Andrea's plugin but we are working on two different branches, did a merge,
Q1/AV: should I move to a different branch? (now using 2.7.0gpu)
A/OM: a bit too early, but eventually yes (3.1.1.lo_vectorization)
Q2/AV: can you recreate helicity recycling so that you run the first run in fortran, then write out to text and then create the final ME in cuda/c++?
A/OM: yes possible, this is Kiran's code, there is a template but it could be moved from fortran to c++... for cpu definitely it could give a big factor, but for gpu it is not clear because the technique consists in storing many results and retrieving them from memory instead of re-computing them, so the compromise may be different in GPU
Q/TC: can we have madevent in c++ eventually?
A/OM: this is not the slow part, it should not make a diffence
C/TC: yes but more people understand c++ than fortran these days ;-)
A/OM: if you find someone who is eager to convert madevent fortran to c, you are welcome! there is also a lot of pythn to rewrite. But what scares me is the fortran, eg there are even parts opf physics for jets written by Stefan Hoeche that would be complex to port.
OM: one more announcement... moving from launchpad bazaar to git! Maybe will be done in a couple of mnths.
Q/SR: on github?
A/OM: not yet clear, using github now, but maybe eventually gitlab
### TC
TC: not much to report, worked on Kokkos code generation, studying MadEvent
C/OM: for madevent should look at latest vectorization branch, as the interface has changed quite a bit
C/SR: this is what I used (see readme in https://github.com/madgraph5/madgraph4gpu/tree/master/epoch2/fortran-cuda)
C/AV: would suggest using the same C interface developed by Stefan for the interface to Fortran (see slides)
### CV
ntr
### WH
ntr, should have some time available by the end of the month
### SR
SR: as reported at last meeting, this Bridge is working, now Andrea has picked this up in new classes
SR: there are some opportunities at CERN to have new students, but will followu p next meetinmg
### NN (joined late)
NN: working on code generation, also debugging a segfault
### AV
AV: presents slides attached to the agenda (very long presentation)
Q/OM: do we really need separate HostBuffer and PinnedHostBuffer?
A/AV: I found it useful to keep them as separate concepts.
Also because in principle an nvcc application might use both HostBufffer's and PinnedHostBuffer's.
But if people prefer one could also have a single class, probably.
C/TC: almost looks like you are reimplementinmg Kokkos!
Be careful not to go too far in abstracting things away.
In particular, some of these optimizations are also done by the Kokkos developers.
A/AV: good point. In any case, you can use the Kokkos optimizations behind this general framework.
You only need to implement three things: the internal implementation of MemoryBuffers,
the internal implementation of MemoryAccess (eg kernelAccessIp4IparConst)
and the internal implementation of kernel launchers (eg computeMatrixElements).
## AOB
Next meeting in two weeks (January 24)