RAMBO with a single final particle? (Do we need sampling in a 2->1 process?)

[valassi]

Hi @oliviermattelaer , next physics question :-)

For the EFT gg>h process of #344: after fixing other generation/build issues I am now getting this warning

ccache /cvmfs/sft.cern.ch/lcg/releases/gcc/10.2.0-c44b3/x86_64-centos7/bin/g++  -O3  -std=c++17 -I. -I../../src -I../../../../../tools -DUSE_NVTX -Wall -Wshadow -Wextra -ffast-math   -march=skylake-avx512 -mprefer-vector-width=256  -DMGONGPU_FPTYPE_DOUBLE -I/usr/local/cuda-11.6/include/ -c RamboSamplingKernels.cc -o RamboSamplingKernels.o
In file included from RamboSamplingKernels.cc:8:
../../src/rambo.h: In function ‘void mg5amcCpu::ramboGetMomentaFinal(mgOnGpu::fptype, const fptype*, mgOnGpu::fptype*, mgOnGpu::fptype*) [with R_ACCESS = KernelAccessRandomNumbers<false>; M_ACCESS = KernelAccessMomenta<false>; W_ACCESS = KernelAccessWeights<false>]’:
../../src/rambo.h:121:60: warning: ‘z[0]’ is used uninitialized in this function [-Wuninitialized]
  121 |     if ( nparf != 2 ) wt = (2. * nparf - 4.) * log(energy) + z[nparf-1];
      |                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~

I looked at the code, and indeed z[0] is never initialized. Initially I was concerned this might be a bug in the translation from Fortran to C indexes, and maybe that I had introduced this in changing the interfaces. But I realised that

• the algorithm is the same, with z[0] uninitialised, in the launchpad cc version https://bazaar.launchpad.net/~madteam/mg5amcnlo/3.x/view/head:/madgraph/iolibs/template_files/rambo.cc#L178
• the algorithm is the same, with Z(1) uninitialised, in the launchpad Fortran version https://bazaar.launchpad.net/~madteam/mg5amcnlo/3.x/view/head:/vendor/CutTools/examples/rambo.f#L36

Eventually, I realised that: maybe we do not need RAMBO (or any other phase space sampling) at all, if we have a 2->1 process?

Rephrasing this: with a 2->1 process do we not always have exactly the same matrix element with exactly the same momenta?

For the specific case of #344, I can see various options

• Change process and get one with two particles (gg to hz?)
• Ignore the build warning (I will probably do this for now!)

More generally:

• Should RAMBO throw an error if used with only one final particle?
• Should we remove the full sampling if we do one final particle (or just forbid this in the standalone test...)?

Thanks
Andrea

[valassi]

The code now builds but indeed the ME is always the same (which is OK), but the weight is negative (which is not ok!)

NumMatrixElems(notAbnormal) = 524288
MeanMatrixElemValue         = ( 2.179124e+02 +- 0.000000e+00 )  GeV^2
[Min,Max]MatrixElemValue    = [ 2.179124e+02 ,  2.179124e+02 ]  GeV^2
StdDevMatrixElemValue       = ( 0.000000e+00                 )  GeV^2
MeanWeight                  = ( -1.462644e+01 +- 0.000000e+00
[Min,Max]Weight             = [ -1.462644e+01 ,  -1.462644e+01 ]
StdDevWeight                = ( 0.000000e+00                 )

[valassi]

Ok thanks to @oliviermattelaer it is now clarified that it is normal that 2>1 processes are special.

The point of gg>h was to check the EFT model. This is now indeed working (PR #352 after fixing #351 and related issues).

I think that this specific RAMBO question for 2>1 can be closed.

[valassi]

In the end I added a simple patch and a warning in PR #365. At least now the final momenta should be correct (previously they were NaN). A warning is written out that the random numbers are ignored.

[valassi]

I am merging a better fix in PR #366