Madgraph5 GPU development

Thursday 4 Apr 2024, 16:00 → 17:00 Europe/Zurich

513/1-024 (CERN)

# Madgraph on GPU developer meeting (Thu 04 April 2024)
https://indico.cern.ch/event/1355149/

Present: SR, AV (minutes), CV, NN, ZW, OM

## Round table

### ZW

Working on reweighting implementations.
Encapsulating them as libraries rather than as separate executables, should be almost done.

OM: AV's work on SMEFT related?
ZW: yes as a use case, but the reweighting infrstaructure is generic.

OM: Marco Zaro said he did some progress on NLO?
ZW: there were some race conditions that he identified, now we are looking at how to fix those
This is all in a separate branch of mg5amcnlo

### OM

NTR

### AV

AV shows the slides attached to the agenda. Some discussion.

OM: about gg>bb, the HEFT Higgs contribution (the fourth diagram) is suppressed with respect to QCD and ius not generated.
To generate it anyway, use 'generate g g > b b~ HIW<=1'

AV: in PR 798 for makefile targets, a lot of code has been removed and cleaned up to simplify the management of common variables across makefiles.
There are two mechanisms for common variables across makefiles: some variables are exported from cudacpp.mk when calling cudacpp_src.mk,
and then there is also a common cudacpp_builddir.mk file which is also included by the fortran makefile.
SR: can this create a race condition? Especially when you have more than one P* subdirectory.
AV: in principle not, it is designed not to have race conditions, and empyrically I have not seen any with 'make -j'.
AV: in any case I will check if 'make -j' is used in the CI tests (which also include some cases with more than one P* subdirectory).

OM: is fptype handled in runcards?
AV: not sure, will check
OM: could put it in make_opts
AV: yes could put it in make_opts (then make_opts would need to be included in cudacpp_builddir.mk, not in cudacpp.mk), or otherwise export an env variable

ZW: should we move to mixed mode by default?
SR: should we try to make it difficult/impossible for users to use FPTYPE=f, which has too low precision?
Discussion
- Agreed that we move to default mixed (in launch plugin for sure; optionally in cudacpp)
- Agreed that we keep fptype in runcard, but invisible by default

### CV

Unfortunately the student has moved to other projects.
Looking for another student to take over the profiling studies.

### NN

Still trying to tackle dynamic shared memory issues.
Attending a SYCL conference next week, will ask around for any good ideas.
Once that is done, should be in good shape to add sycl to cudacpp.

SR: involved in a EU project on RISC-V. In contact with codeplay there. Maybe I can put you in contact with them?
NN: already in contact with Codeplay through Argonne.
NN: using Intel dpc++, but pure sycl, nothing in oneAPI namespace.

### SR

Opened a PR for channel Ids. Should be functionally complete.
The CI tests are failing, will look at fixing those.
Then will regenerate processes.

Important: relying on the fact that in good helicities the channelis are not used.
So rely on the fact that channel ids are all 0.
One caveat is that is that when you "new" the memory I had to set values to 0 in cuda (cudamalloc does not do this)
NN: memset?
SR: memset did not work because of some int vs unsigned int issue, so use std fill.
AV/NN: but maybe 0 should be 0x00000000 anyway? and same size?

OM: sounds a huge overkill to use GPU for computing helicity recycling? should we use fortran?
AV: well the GPU is just underused, better than have the gPU wait for fortran 

AV: are you not using the new function to get good helicities with no channel id?
SR: yes using this function, but there is then another problem where this appears

SR: for tests we need a new reference values
AV: probably can keep the old test with all channels equal, and a new test with different channels

SR: do not remember how channels are used in runTest.exe
AV: not sure, maybe channel 0 so it was working with both mad and sa
AV/SR: anyway, probably need to write a new test for this functionality

## AOB

SR: we have done the selection of the QUEST candidate at CERN, will most likely start in June

Next meeting?
SR: will not be around Tue 16, can we do Mon 15?
AV/OM: ok
ZW: away the whole week
SR: ok so lets do Mon 15

OM: AV you want to have a chat next week? git repos, PRs etc
AV: yes good idea

16:00 → 16:10 News

16:10 → 16:30 Topical discussion

valassi-20240404-MGonGPU-v001.pdf

valassi-20240404-MGonGPU-v001.pptx

16:30 → 16:50 Round table

16:50 → 17:00 AoB