Workplan (December 2022) towards a first alpha release

[valassi]

I have now completed the random choice of helicity #403 and color #402, which means that the cudacpp version is now functionally complete (at least for the simple processes we tested...).

I am listing here my understanding of what we still miss towards a first alpha release for the experiments

1. (For Olivier) Check that the color numbering used in coloramps.inc (and copied as-is in coloramps.h) is the correct one. This is needed even if we give to the experiments some pre-generated gridpacks rather than a code generation framework.

2. Backport to mg5amcnlo all code generation patches that are presently in madgraph4gpu. This includes amongst other things:

• merge the two patches I already packaged as MRs First set of vector.inc changes for cudacpp integration mg5amcnlo/mg5amcnlo#23 and Second set of vector.inc changes for cudacpp integration (make VECSIZE_USED a function argument) mg5amcnlo/mg5amcnlo#24: I suggest using gpucpp as the upstream mg5amcnlo branch for the alpha release
• if still needed/relevant, fix conflicts and merge Olivier's MR Lo vect diagid mg5amcnlo/mg5amcnlo#5
• remove my patch for generating coloramps.h from coloramps.inc: instead, coloramps.h should be generated correctly from the Python itself... this may need or be solved by Lo vect diagid mg5amcnlo/mg5amcnlo#5 above
• prepare a new MR to replace my patch.common and patch.P1 patches for the Fortran files (and anything else in my patchMad.sh script)
  NB This point 2 is the only thing that we may be allowed to bypass if we give pre-generated gridpacks to the experiments. I would still focus on this before the alpha release for our own sanity in development (we already hav etoo many mg5amcnlo branches for the gpu work)

3. Clean up the build and runtime environment and options so that the experiments can use this out of the box. The aim (assuming point 2 is also done) is that you run a "launch" command from the MG5aMC prompt and everything works. This includes (possibly non-exhaustive list).

• as suggested by Olivier, make sure that the madevent input files have the same format as they have always had: this means removing the two first extra arguments I added, for Fortran/Cudacpp/BothDebug and for VECSIZE_MEMMAX... a quick and dirty workaround may be to use environment variables instead
• clean up the executable names and define a mechanism to choose one: now I have madevent, cmadevent_cudacpp, gmadevent_cudacpp, we need a mechanism to choose one
• similarly, define mechanisms for which build to use (float/double, avx/avx512, etc)... we now have environment variables (or make variables) for this, this could be ok
• when the points above are done, in particular the madevent input files, these software changes must be backported to code generation (in my scripts and - point 2 - in mg5amcnlo upstream)

4. Cross check what we are doing with parameter choices. Keep a parameter card to read at runtime, or use the uopstream mg5amcnlo mechanism to transform the parameter card into code that must be built? Again, once this is sorted out, it must be backported to code generation in my scripts and/or better (point 2) upstream

5. TEST! As mentioned above, we should be able to just "launch" a MG production from the existing infrastructure, i.e. no change in user interface for the experiments. If we already manage to do this for one of our current processes like ggtt, this is great. Check that the results (cross sectiond and LHE files) are the same in Firtran and cudacpp. This will require some tweaking of event numbers, esepcially in cuda. This test should, in particular, include the autoamtic running of madevent in the different integration channels, the creation of G subdirectories, the launching of a web browser with autoupdated results etc.

6. New processes. Until point 5 above we can even just use gg to tt. We need more things including

• make sure the whole infrastructure works with protons and pdf, eg pp to tt
• check also processes with more than one P1 subdirectory
• if needed, check processes with nprocesses>1 inside the code
• try the susy processes suggested by ATLAS and CMS... these are BSM processes and code generation may have other surprises

Comments welcome!
Andrea

[valassi]

Note: one large and essential part of point 3 (actually, it comes before point 3 and even before point 2) is the need to make all process directories relocatable (ie it must be possible to build them standalone outide madgraph4gpu), in particular see the tests and common random numbers

[valassi]

I have created an updated workplan #671, mentioning an dupfdaing most issues above - this issue #576 can be closed