Repository navigation
Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels #356
Description
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.
Activity
valassi commentedon Jan 26, 2022
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
[heft] temporarely add the full heft_gg_h code to the repo
[heft] trivial fix for the Higgs mass in EFT: use Parameters_heft::ge…
oliviermattelaer commentedon Jan 27, 2022
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...
[shared] FINALLY remove niterations, gpublocks, gputhreads from CPPPr…
[shared] move CPPProcess from fsampler to fbridge - CPPProcess should…
valassi commentedon Apr 22, 2022
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
valassi commentedon Apr 26, 2022
On a different note, presently CPPProcess is a rather dummy and unclear class. It must be called to be sure parameters are read from card files, but then it can go out of scope (see fbridge.cc). Should it be a singleton? Do we need this class at all? Note also that the reading of parameters from the card file in cudacpp is something to be reviewed in itself - should this be done in Fortran? Its it ok to use the hardcoded option because in any case runcard also in Fortran is used to generate fortran code?
[alphas] incomplete attempt to set G=1.2177157847767195 from aS: it b…
[-]Clarify roles of CPPProcess and MatrixElementKernels[/-][+]Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels[/+]valassi commentedon May 6, 2022
I added Parameters_sm and renamed this as "Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels".
This is related to #439: I need to fix the way parameters are handled, specifically in EFT, after we added the running of alphas event by event. This in itself would be easier if the interaction of Parameters_sm and CPPProcess was streamlined and simplified. As an alternative to hardcoding everything (with a madevent treat cards) as I suggested in #439, one can still read cards at runtime, but the Parameters_sm singleton should probably do the reading of cards itself.
valassi commentedon May 22, 2023
I closed #301 as done (MatrixElementKernel). In this #356 some cleanup of all that stuff remains to be done (eventually, low priority)
[heft] new FPE strategy madgraph5#831 - in CODEGEN for MatrixElementK…