Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels

[valassi]

This is an important "internal API" issue in the line of those discussed in #323.

I would like to understand how to restructure the collaboration between the code in CPPProcess and MatrixElementKernels. Should these actually be merged? If possible, maybe I would avoid that, as there is some boilerplate-like stuff that can go in MatrixElementKernels independent of the physics process.

@oliviermattelaer, @roiser, copying you explicitly on this one if you have feedback....

The CPPProcess class could probably be renamed as "PhysicsProcess", to give "process" a different meaning: not a CPU process, but a physics process. In fact, CPPProcess.h/cc are now the files where most of the physicsprocess-dependent code resides (essentially, how to assemble the various FFV/XXX to make a matrix element calculation, and also the reading of parameters, and also the color algebra).

CURRENTLY, note that this is quite peculiar:

• check_sa creates a CPPProcess instance (one in the app, but not a singleton pattern with static methods)
• this CPPProcess actually reads the physicvs process parameters from file, and then copies them to C++ static memory or to CUDA global memory (unless they are hardcoded, see PR Option to hardcode physics parameters (with hacks to remove) #306): one problem however is that this is not yet done for EFTs (Code generation for EFT gg>h : issues with model parameters #351)
• from this point on, essentially no one needs the CPPProcess instance at all: the physics parameters are in static/constant (essentially the parameters are singletons, which makes sense), and it is from there that calculate_wavefunctions itself reads it, to put it in FFVs
• it is kind of an accident that calculate_wavefunctions is also in the CPPProcess FILE, in the sense that in any case it does not read member functions of CPPProcess: it actually is not a memeber function of the CPPProcess class, it is a standalone function (as if it was a static function of the CPPProcess class)
• similarly, claculate_wavefunction is only used by the sigmakin functions, which are themselves also standalone c++ functions, or standalone CUDA kernels, not belonging to a class

I would say there are two/three things that can/must be fixed/clarified

• whether cpprprocess needs to be a singleton or a class with many instances (I guess the former)
• the handling of parameters, also to fix EFTs (one way could be to make parameters available from the cppprocess singleton, so that in cases like EFT where they have not - YET - been copied to constant memory, there is an easy way to retrieve them)
• most importantly, the design of the calculate_wavefunction/sigmakin and their interaction with MatrixElementKernels: the point is that splitting kernels (Split the sigmakin kernel into smaller kernels #310) needs variables such as amplitudes and wavefunctions that are potentially local to classes (unless they are in cuda global memory or c++ statics), so somewhere there you need a real instance which holds these memory buffers, not a static singleton

I will try out a few options.

[valassi]

Ok I see now that the Parameters class already is nicely a singleton. This should make it trivial to fix the EFT issue in #351

[oliviermattelaer]

Hi Andrea,

If you want you can contact me on skype on Friday such that we can discuss this, I'm a bit lot in the seas of issue...

[valassi]

This is an issue with many small ramifications.

Clearly one of the main points here is defining the roles, responsibilities and APIs of CPPProcess and MEK with respect to splitting kernels #310.

The most immediate question I am facing is in the context of PR #434 for the running of alphas #373. I just added some comments in #373. One issue is that gc10/gc11 are process specific for ggtt, but for instance do not exist in eemumu. So I would leave only the gs as a high level interface, and move gc10 and gc11 to "internal implementation" not exposed in the bridge for instance, Technically, computing the dependent couplings becomes one instance of "splitting kernels" #310 and there are quite a few issues to solve there about the best APIs and responsibilities for the classes, eg CPPProcess and MEK #356. In practice: where should the orchestration of kernels be, in MEK or in CPPProcess? This is relevant to code generation because the prchestartion of kernels (how many kernels you have and in which order you run them) is process specific. Until now MEK was a process agnostic class. So I have a decision to make, departing from what was done so far

• either MEK starts including process specific stuff, unlike what it did so far
• or CPPProcess starts taking the role of launching kernels, which so far was exactly the role of MEK