Choose timezone
Your profile timezone:
Madgraph5 GPU development
→
Europe/Zurich
Virtual (Zoom)
Virtual (Zoom)
Stefan Roiser
# Madgraph meeting Mon 24.01.2022
Present: AV (minutes), OM, DavidS, CarlV, WalterH, NathanN, TaylorC, SR (a bit later)
## News
(AV: SR will be a bit late)
AV: discussing a possible doctoral student, Stefan may say more
## Round table
### David
DS continuing work on Alpak code generation (Stefan suggests to make a runtime comparison)
Using goldenX4 tag as baseline, built code generation for Alpaka over that
Code was compiling but was getting a runtime error, should now be fixed (though ME is 0 now).
Problem was that all alpaka kernels are templated, the issue was in which object files to compile and link
(note that cuda was doing JIT compilation, was getting "JIT error during PTX compilation").
AV: try to have alook at -arch options, there are two separate ones for SASS and PTX
(never tried to tweak anything related to this, still using Stefan's two year old options there).
AV: is this in github?
DS: no in my private area, will make a PR as soon as ME=0 is fixed
### Walter
Started looking at this at cuda bridge to see how to interface to Kokkos
### Taylor
Ntr
### Nathan
Sent a PR for sycl, fixed an issue in complex numbers and simplified kernel launching
Also took away many ifdefs
Backported to sycl, tested on a bunch of different platforms
AV: documentation?
NN: good point, will write a README or twiki
### Carl
Question: would performance profiling test be useful at this stage?
AV: maybe for nvidia comparison between cuda/kokkos/sycl/alpaka, profiling would be dgood
TC: would not look at algorithm profiling before we do a publication and LHC experiment usable
AV: completely agree - what I meant is try to understand at low level (nsight compute)
any differences between the different plugins
TC: a real comparison would be madevent in all plugins
OM: technically not the same cross section and event generation
AV: two options, publish based on what we have without madevent, or wait for madevent - Taylow what do you prefer?
TC: for a first iteration we can use rambo without going for madevent
We could build up on the CHEP publication, then MadEvent would be another publication
OM: a bit confused, very different to target madevent or to target a paper without madevent
AV: a suggestion could be to have documentation for all to run it and get results
OM: we could target this as one goal for the next two weeks
SR: which processes?
AV: three processes we have
TC: would agree
OM: would even go beyond
AV: I would not add new processes
TC: where? published in Elsevier CPC but would avoid it. Maybe sciam?
OM: would go for EPJC, they forbid manuals but like code
TC: also PhysRevE
SR: CSBS Springer
AV: agree EPJC or CSBS
TC: maybe Olivier defines processes first, where we can hit the button for code generation
OM: should exercise different physics
AV: would try eemumu, ggtt, ggttgg
AV: can you confirm you are using golden epochX4?
NN: no using the latest version as of today
TC: maybe latest was epoch2
AV: I am happy to us ethe latest greatest (easier for me!) but it may have algorithmic improvements
(and there are also compiler improvements!)
SR: Andrea maybe you can still try to publish number for epochX4 and see what changed
=> AGREE in two weeks to try to compare the numbers
OM: will create an issue for the comparison
### Olivier
Progressed on MadEvent side.
Changed the base plugin which is below Andrea's plugin, to b eable to produce not only ME,
but also ME times additional factor
AV: if you want me to add these two lines of code to my stuff directly I can try
OM: will add this to base plugin, then porting to Andrea should be easier
SR: was this the factor 0.87 difference?
OM: no that was alphas
OM: also testing pp to tt, found some issues that Andrea is working on
OM: so for Taylolr, MadEvent is not that far away, a first test maybe less than one month
AV: ? wait for paper?
OM: no having two papers makes sense, production MadEvent is not for tomorrow
### Stefan
SR: received an email from Intel about OpenLab project on oneApi/sycl, they want to knos if we continue
Probably if we say yes we will get access to some hardware
AV: the hardware is already there, so we should stay there
SR: discussing a PhD proosal with Vienna university
Would probably be on unweighting and on NLO
SR: in contact with a high school student who was doing some jupyter work,
will ask him to present stuff at a meeting
SR: discussed bridge with Andrea
### Andrea
Presents some slides
- Slide 3
OM: maybe function only used by uutt because of Z
OM: also another fix, will create a PR
OM: nprocesses=2 may actually be uubar and ubaru to ttbar, not the same!
AV: ok I let you have a look at it
AV: not sure if problem in my plugin or in base stuff
OM: probably in base stuff! will have look at it
- Slide 4
OM: not sure what I prefer!
OM: not sure how we pass parameters from Fortran to C
SR: ok if there are other parameters to pass anyway, maybe drop option 1
OM: maybe option 2 sounds a bit cleaner, but no big difference
SR: fine for option 2
NN: added flexibility in option 2 is better, personally
- Slide 5
OM: having 123+1 kernels might be complicated, it has a cost because now w_sv are reused
OM: in pother words, each diagram has ALSO some w_fp as output!
AV: good point, was overlooking this
AV: can make amp[0] a scalar?
OM: yes this has changed between fortran and c++, in fortran jamp sums was at the end
SR: probably need cuda graphs?
OM: but I fully agree on first step, splitting the color algebra as a second kernel
OM: for other steps low priority (go for madevent first)
OM: note again that tensor cores scary if it is singl eprecision
- Slide 6
NN: had similar issues about
OM: maybe need new driver
NN: yes but then still support older cuda
OM: will contact IT team to install CUDA 11.6
## AOB
Meet again in two weeks and try to have numbers for the comparison
There are minutes attached to this event.
Show them.