Choose timezone
Your profile timezone:
Madgraph5 GPU development
→
Europe/Zurich
Virtual (Zoom)
Virtual (Zoom)
Stefan Roiser
# MG meeting Mon 14.06.2021 Present: AV (notes), OM, SR, SH, AR, Carl, Walter, Laurence (partly) ## Olivier's slides Diagrams of reengineering needed to integrate CUDA and vectorized C++ ME calculation into MadEvent. FIRST PART Slide "17" old design Slide "18" new design - Cuts are now much higher, good for vectorization, but you do not know yet the flavor - Couplings are different for different momenta! Slide "19" important changes - For each event a helicity was picked, now this is no longer the case - Need some API to know exactly the inputs and outputs... Slide "20" validation - Old fortran, new is "vector" loops from slide 19 (but all in Fortran, not vectorized c++!) The central value is similar, but what is surprising is that the - AV: it would be useful to know exactly the number of weighte events, I guess the error scales with (1/sqrt) the number of weighted events, not the 500k unweighted AV: observed issues in gridpack OM: that may have been because if iyou increase #unw events, you open up new channels - SH: how is the error computed exactly, it would be useful to have the formula AV: I thought we would have several vectors for different flavors? OM: yes down like this in this new version, we pass several vectors with different flavors AV: running couplings? OM: only QCD alphas is running, not the QED couplings (maybe eventually they should , too) AV: can we not compute the alphas from momenta in c++/cuda? we hav ethe momenta? OM: maybe, but for now thinking of doing it in fortran AV: then we need to extend the API to also pass the alphas SR: what are the sizes of the 'baskets' you pass? rembebre in cuda we have many events (eg 16k in ggttgg) OM: strict minimum is 32 threads per warp AV: you are both right, now we need 16k, but eventually we could split up, down to basktes of 32 SECOND PART input/output Slide 22 inputs - You pass as input the index of the diagram which is being analysed by MadEvent (MadEvent has many independent executions, once for each diagram) Slide 23 outputs - Rather than |M|2, need that multiplied by the 'weight' of the diagram which is being analysed (In any case, it is a single number) - Output ALSO one helicity picked at random according to the weights of all helicities - And need the jamp2, ie the vector of partial amplitudes (one number for each color flow) (Example ggttgg there is a 24x24 color matrix, jamp2 is 24 partial amplitudes) Or maybe can try to pass only one of the jamp2, the one which would be picked for parton showering? AV: very good to have inputs and outputs! it helps a lot for modularity to have pure functions with clear inputs and outputs Eventually we may think of having more than just the ME calculation API Example: running of alphas also is a pure function, momenta as input, alphas as output Example: given the full jamp2 vector, also the choice of which color flow to pass to PS is also a pure function The idea is that if we have clear input/output interfaces, all these components become plug and play that can live in fortran, c++ or cuda AV: maybe we can focus on just ggttgg for the rest, rather than a fully generic case? In other words, move fro eemumu to ggttgg as our default? SR: too complex, maybe eemumu? AV: maybe ggtt then? simple enough, but at least it has QCD... we need a non-trivial jamp2 (more than one color flow) OM: ggtt should have at least two color flows, it should be ok in that respect OM: but then AV can you implement vectorization by hand for ggtt? AV: ok will do eventually, should not betoo complex SR: what is the indexing of the Fortran data structure, is there any flexibility? OM: presently three indexes in this order, Lorentz, particle, event index... not much flexibility, would keep it this way ## Carl's slides Question about float compilation Got a compilation error AV: please open a bug, solved similar things (using std, sqrtf etc) for eemumu SH: could have alook later today AV: please have a look at eemumu too, would be useful to do it in the same way [Some discussion offline after the meeting, candidate patch by AV in https://github.com/madgraph5/madgraph4gpu/pull/211] ## Round table OM: nothing else CV: nothing else SH: in contact with LLAMA developer to have a look, would not impact other people's work SR: good, could be useful for HEP in general AV: good could be useful, probably not for madgraph (too simple) OM: will ask SH some questions about openmp for fortran AR: trying the profiler also on kokkos, got some issues with directory naming AV: completing the paper, will circulate it to SR/OM/SH for feedback ## AOB - Madflow SR: never discussed here explicitly about madflow, SR/OM/AV had a discussion with them which was useful, TC had asked a questions about it - we can discuss more in detail when Taylor is back ## AOAOB Another meeting next week, then we ses AV: probably will not be there AV: if I need to manually vectorize ggtt, maybe we postpone the meeting about code generation? OM: yes prefer to postpone that, I would have to spend some time preparing that
There are minutes attached to this event.
Show them.