Improve handling of model parameters

[valassi]

This very generic task "Improve handling of model parameters" is a follow up to #439, which was specifically for EFT models after inroducing the running of alphas. That specific issue is closed by PR #446, which however only works with the branch where parameters are constexpr ('#ifdef MGONGPU_HARDCODE_PARAM'), while it does not work if parameters are in c++ memory or in cuda constant memory.

It is also a followup to #39 and its PR #306, which were about introducing a first version of computations where parameters are hardcoded constexpr (the '#ifdef MGONGPU_HARDCODE_PARAM' above), rather than variables in memory or in cuda constant memory. That patch was completed and depended upon introducing a simple complex class cxsmpl with constexpr arithmetics ie issue #307 and its PR #327, which have also been completed.

It is also related to the class design issues discussed in #356 (even if those are a bit orthogonal).

It is also related to some possible future extensions to allow event by event reweighting with differenet parameter sets (#447).

More concrete details below.

[valassi]

To be more concrete, following some ideas from #439, I think that it would be nice to implement the following:

• It could make sense to replace the runtime reading of param_card.dat by a compile-time reading of this file to create a header param_card.h. This is exactly what the Fortran already does, ${dir}/bin/madevent treatcards param reads the dat file and creates a .inc file. This would be useful in many ways: you no longer need to handle card files and their path at runtime; you can create hardcoded constexpr using non-default values of the parameters (which is especially needed eg for EFTs).

• Even if parameters end up being hardcoded in constexpr in a param_dat.h, it is still not clear to me if runtime performance is faster with such hardcoded constexpr or not. In other words, is the option HRDCOD=1 ('#ifdef MGONGPU_HARDCODE_PARAM') faster than HRDCOD=0 ('#ifndef MGONGPU_HARDCODE_PARAM')? I am not sure, this should be studied. Maybe it is still better to copy those hardcoded parameters to cuda constant memory for instance? One should understand this and decide if the cIPC/cIPD mechanism has to be enhanced, or instead completely removed. One idea in particular could be to replace the cIPC/cIPD by a struct with named variables, that exists in c++ an dcan be copied byte by byte in cuda constant memory?

• The previous point is relevant for instance to EFTs. Presently (partial fix for EFT processes after merging alphas (only workd with HRDCOD=1 for now) #446) EFTs code only builds and runs correctly '#ifdef MGONGPU_HARDCODE_PARAM'. This is because the calculation of aS-dependent parameters event by event, in a cuda kernel, depends on other model parameters that are not available in cuda device code (unless they are hardcoded as constexpr, thanks to '#ifdef MGONGPU_HARDCODE_PARAM'). As I mentioned in partial fix for EFT processes after merging alphas (only workd with HRDCOD=1 for now) #446, one relevant question is, what determines what is in self.parms2order and self.coup2order in code generation? These are the only pieces of the Parameters.h file that are presently copied to constant memory, we may want instead to enhance the cIPC/cIPD by copying more parameters and couplings there.

• One final point, that touches both Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels #356 and Event by event reweighting using matrix elements computed for different parameter values #447: I think it would be useful to have a Parameters class that is actually a "parameter set". Whether one foresees having more than one parameter set (as in reweighting Event by event reweighting using matrix elements computed for different parameter values #447) or not, from a class design point of view (Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels #356) I think that it makes sense to encapsulate a given set of parameters in a class/struct instance, essentially Parameters.h. It is then up to the interplay with the rest of the code and mainly CPPProcess to understand if this is a singleton or not.

• (PS One point that should also be mentioned, but I find low priority, is improving the float SIMD handling of parameters in EFTs: currently in PR partial fix for EFT processes after merging alphas (only workd with HRDCOD=1 for now) #446 this is disabled, because of various issues. Essentially I loop through ieppV explicitly in a SIMD vector, ie there is no SIMD in G2COUP. One possibility could be to cast all parameters from double to float in the formulas that compute the fptype_sv aS-dependent parameters and couplings, but this seems complex. Some of the ideas above may also help here)

[valassi]

As part of #630 and WIP MR #706 I am doing tests changing the top mass.

If I change the card.dat, then the card.inc for fortran is regenerated. However the hardcoded parameteres for cpp are not. So there is certainly at least one bug to fix: HRDCOD=1 parameters should be regenerated from the param card.dat