Fix heft generation after alphas PR: more fundamentally, remove reading of param_card.dat?

[valassi]

Hi @oliviermattelaer @roiser I am finally about to merge the alphas PR #434.

As one last check, I wanted to check that heft models also work fine - they do not.

I have fixed the simple stuff (like _sm vs _heft suffixes), but there is one fundamental issue: the code to compute the dependent couplings depends itself on several parameters that I had not exported there. See below a full example.

The problem here is quite fundamental, in the sense that normally these parameters are available through the Parameters_sm instance, somehow available through the CPPProcess instanc (things that I think we should review anyway). Anyway, the computation is now part of a device function (host device inline const DependentCouplings_sv computeDependentCouplings_fromG) which can be in a kernel. If all those other parameters must be available in a kernel, one must copy them there to device memory, especially if they are read at runtime from a runcard file. The alternative is that they are taken from somewhere hardcoded in the code (where they are sent at generation time - this is what I did in the HARDCODED ifdef branch, so you see that in the full files I attach these are available.

My question is,

• should we continue supporting reading of runcards at runtime?
• or can we assume (as it is done in the fortran code in one step during the make process) that these end up into a hardcoded code file instead?
  The latter solution would considerably simply things.

• In practice, I am asking whether we should use my 'hardcoded' branch as default and drop the runtime reading of runcards. *

This is certainly not a priority, but I raise the issue here for reference. I will merge the alphas PR as is, without support for heft...

Thanks!
Andrea

PS Example from my autogenerated code

namespace Parameters_heft_dependentCouplings
{
  constexpr size_t ndcoup = 1; // #couplings that vary event by event because they depend on the running alphas QCD
  constexpr size_t idcoup_GC_13 = 0;
  struct DependentCouplings_sv
  {
    cxtype_sv GC_13;
  };
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"  // e.g. <<warning: unused variable ‘mdl_G__exp__2’ [-Wunused-variable]>>
#pragma GCC diagnostic ignored "-Wunused-parameter" // e.g. <<warning: unused parameter ‘G’ [-Wunused-parameter]>>
#ifdef __CUDACC__
#pragma nv_diagnostic push
#pragma nv_diag_suppress 177 // e.g. <<warning #177-D: variable "mdl_G__exp__2" was declared but never referenced>>
#endif
  __host__ __device__ inline const DependentCouplings_sv computeDependentCouplings_fromG( const fptype_sv& G )
  {
    // Model parameters dependent on aS
    //const fptype_sv mdl_sqrt__aS = sqrtNR( aS );
    //const fptype_sv G = 2. * mdl_sqrt__aS * sqrtNR( M_PI );
    const fptype_sv mdl_G__exp__2 = ( ( G ) * ( G ) );
    const fptype_sv mdl_GH = -( mdl_G__exp__2 * ( 1. + ( 13. * mdl_MH__exp__6 ) / ( 16800. * mdl_MT__exp__6 ) + mdl_MH__exp__4 / ( 168. * mdl_MT__exp__4 ) + ( 7. * mdl_MH__exp__2 ) / ( 120. * mdl_MT__exp__2 ) ) ) / ( 12. * ( ( M_PI ) * ( M_PI ) ) * mdl_v );
    const fptype_sv mdl_Gphi = -( mdl_G__exp__2 * ( 1. + mdl_MH__exp__6 / ( 560. * mdl_MT__exp__6 ) + mdl_MH__exp__4 / ( 90. * mdl_MT__exp__4 ) + mdl_MH__exp__2 / ( 12. * mdl_MT__exp__2 ) ) ) / ( 8. * ( ( M_PI ) * ( M_PI ) ) * mdl_v );
    // Model couplings dependent on aS
    DependentCouplings_sv out;
    // FIXME? should this use a model-dependent mdl_complexi instead of a hardcoded cxmake(0,1)?
    out.GC_13 = -( cxmake( 0., 1. ) * mdl_GH );
    return out;
  }
#ifdef __CUDACC__
#pragma GCC diagnostic pop
#pragma nv_diagnostic pop
#endif
}

[valassi]

I clarify my own comment and change the title: the parameters come from param_card.dat, not from run_card.dat.

In generating ggtt.mad I launch the following steps, which normally are part of 'cd Source; make':

madgraph4gpu/epochX/cudacpp/CODEGEN/patchMad.sh

Line 20 in 605291c

# These two steps are part of "cd Source; make" but they actually are code-generating steps

# These two steps are part of "cd Source; make" but they actually are code-generating steps
${dir}/bin/madevent treatcards run
${dir}/bin/madevent treatcards param

The fact that I do this at 'generation' time is only in my own scripts, because I want to commit to the repo some ggtt.mad code that includes all the code.

For a normal end user, I do not suggest to change the way of working: the paramcard.inc (Fortran) would be created when doing make from Source,
https://github.com/madgraph5/madgraph4gpu/blob/605291c3f527c3d1380f56fe96287ef401e23a41/epochX/cudacpp/gg_tt.mad/Source/param_card.inc
and similarly the runcard.inc
https://github.com/madgraph5/madgraph4gpu/blob/605291c3f527c3d1380f56fe96287ef401e23a41/epochX/cudacpp/gg_tt.mad/Source/run_card.inc

What I am suggesting here is that also in the cudacpp plugin we should have a similar mechanism: as part of the make process in the src directory, we should have a mechanism to create param_card.h (and run_card.h?) which are pieces of code that we can then use inside cpp/cuda. This would remove the need to read the param_card.dat file at runtime.

Note incidentally that the .inc created for Fortran are not good for c++, because I would prefer to hav ea c++ style 'constexpr <param_name> = <param_value>;', while the Fortran.inc is only '<param_name> = <param_value>' (and even the format of the value may be Fortran specific (is D valid in C, I do not remember?)

MDL_WZ = 2.441404D+00

should become

constexpr double MDL_WZ = 2.441404E+00;

(or maybe with fptype instead of double).

[valassi]

Incidentally again note that the constexpr above ALREDAY IS in the cudacpp generated code

madgraph4gpu/epochX/cudacpp/gg_tt.mad/src/Parameters_sm.h

Line 176 in 605291c

constexpr double mdl_WZ = 2.441404e+00;

  constexpr double mdl_WZ = 2.441404e+00;

However:

• this is at generation time, not at build time; it comes at generation time from some defaults in MG5aMC (no reading of user param card); so it should come at build time from reading of user param_card instead
• it is only enabled in the part of the code protected by '#ifdef MGONGPU_HARDCODE_CIPD' (which in Fix uudd in generation after the alphas merge #440 I suggest should be renamed '#ifdef MGONGPU_HARDCODE_PARAM' anyway): what I am suggesting here is that this (or selected parts of this) should become the default... we should not have BOTH a runtime reading of param_card.dat AND a build-time reading of the same file to create param_card.inc... as in the Fortran, I think that it makes sense to ONLY have the param_card.h approach (in particular param_card.h could become a drop-in replacement inside Parameters_sm.h for those parts of the code)

Note incidentally that removing the runtime reading would remove all complications about locating the param_card.dat file itself, see issue #194 about MG5AMC_CARD_PATH)

[valassi]

Incidentally again, the approach I suggest here would solve yet another (real? imagined?) problem,

    // FIXME? should this use a model-dependent mdl_complexi instead of a hardcoded cxmake(0,1)?

In the parameter calculations, an mdl_complexi was used in the past; after the alphas merge, I hardcoded this to (0,1). I have no idea if peculiar EFT models assume a value of complex i which is not (0,1) as an artefact of the model. I find it unlikely, but maybe it is a parametrization? Anyway, in th eapproach above the mdl_complexi, like all other parameters, could be coming from the param_card.h that ultimately comes from param_card.dat.

(I do not see any way to change complexi in https://github.com/madgraph5/madgraph4gpu/blob/605291c3f527c3d1380f56fe96287ef401e23a41/epochX/cudacpp/gg_tt.mad/Cards/param_card.dat, anyway)

[oliviermattelaer]

So here we can really assum that mdl_complexi will always be cxmake(0,1)