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)

[valassi]

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

Hi Olivier, thanks, for completeness I checked the code, this comes from models/import_ufo.py

    def shorten_complex(self, matchobj):
        """add the short expression, and return the nice string associate"""
        
        float_real = float(eval(matchobj.group('real')))
        float_imag = float(eval(matchobj.group('imag')))
        if float_real == 0 and float_imag ==1:
            new_param = base_objects.ModelVariable('complexi', 'complex(0,1)', 'complex')
            self.add_parameter(new_param)
            return 'complexi'
        else:
            return 'complex(%s, %s)' % (matchobj.group('real'), matchobj.group('imag'))

So it is indeed hardcoded, I will hardcoded in a better way (in a better place) for cuda/cpp then.

[valassi]

I am about to merge PR #446 that will provide a first partial (but functioning) patch for EFT models with running alphas.

A few comments about what this patch does, with respect to some of my earlier comments above

• The patch only works if parameters are hardcoded rather than read from file. This is of limited usefuleness now, because the hardcoded parameters are those that are default in MG5AMC (ie there is no way for users to change them, other than modifying the code), but at least the code is fully functioning. I will open an issue to follow up on this one, with various options (such converting card files to hardcoded parameters, and in any case using them as variables in memory rather than constexpr in calculations).
• The hardcoding is now protected by '#ifdef MGONGPU_HARDCODE_PARAM' ie. the previous _CIPC or _CIPD has been renamed to make it a bit more general.
• The patch was much more complex to complete than I expected, because it sits at the interplay of various delicate issues. One example, the fact that parameters are double (this was my choice initially) while MEs can be float introduces some problems: multipplying a scalar double and a SIMD vector of floats is not possible as-is in the compiler, an dintroducing casts at the right place would be rather complex to code generated (workaround, in this case I give up SIMD and iterate through each SIMD element one by one). Another example, the interplay of the cxsmpl class that I used for having constexpr constants and of cxtype for instance in cuda also forces some conversions that are a bit tricky.

Anyway, the immediate issue of this #439, namely that EFT was not at all working with running alphas, is now fixed (in on e particular case), and I will merge it. As for the next steps, rather than continue here, I will open a new issue which will hopefully clarify a bit better what is remaining - and in any case will be lower priority.

[valassi]

This #439 is now closed by PR #446. The remaining issues are in #448.