Madevent integration: production mode for user, developer mode for performance tests (madevent script rather than symlink?)

[valassi]

Hi @oliviermattelaer @roiser this is a placeholder for later explaining the design ideas I am following in the integration of madevent.

Essentially we have two use cases and we need two modes: a production mode for users, a developer mode for performance tests.

For the production mode, as suggested by @oliviermattelaer, I am sticking as much as possible to the current Madgraph user interfaces and internal tools. In particular, the use of runcards, the rebuilding when runcards are modified, etc. (Olivier I hope that sounds good?). One notable example is also that I have removed the two additional parameters in the input file to madevent (#658) in MR #688.

However I also think we need to be able to use a developer mode, to do performance testing, vary a few internal parameters etc. I have hidden (or I am hiding and am going to hide) these into internal hooks that should not be used by normal users. For the moment I am using a few environment variables (eg the bridge mode and vecsize_used): actually these hooks may even be removed completely at some point, they may have served their purpose. One important part of this developer mode that I need to still implement is the "build many backends once, then test them all in a row without rebuilding" (extensing much further the switch in #674). This may be a fourth cudacpp_backend target, for instance where "madevent" is not an executable but a shell script that acts as a dispatcher. Whatever... I will think about it later. Maybe not even completely needed. For the moment I am focusing on the production mode, as close as possible to the original.

Ah one detail: while I removed vecsize_used from the runcards (because the point of this was exclusively that of being a runtime parameter without rebuilding), I am thinking of adding vecsize_memmax to the runcard. This is really something the runcard is about: your change that, and you force a rebuild (vecsize_memmax is a build time parameter). This is something also for production users. Note that the default of vecsize_memmax now is determined at generation time (output madevent .. --vector_size=xxx)... but I think it makes sense to add that to the runcards. [PS edited: yes, this is exactly what Olivier had suggested here https://github.com/oliviermattelaer/mg5amc_test/issues/9]

[valassi]

I mentioned madevent as a script explicitly in the title. This is related to

• Option to produce multi-build (fortran, cuda, cpp) gridpack #945 multi-backend gridpacks (which means you choose a backend at runtime, not at build time)
• madeventfortran vs madeventcpp vs madeventcuda #674 backend choice in launch (but this is essentially already done via runcards, for the choice of a build at build time)