Clarified: gg_ttggg has 1240 diagrams in CPPProcess.cc but only 1122 entries in channel2iconfig (and 945 config)

[valassi]

Hi @oliviermattelaer here I am lost. This is in master.

I just realised that gg_ttggg has 1240 diagrams in CPPProcess.cc
https://github.com/madgraph5/madgraph4gpu/blob/606ee3bd25a9dd9f452094265116d5dcd20304ac/epochX/cudacpp/gg_ttggg.mad/SubProcesses/P1_gg_ttxggg/CPPProcess.cc#L29944

      // *** DIAGRAM 1240 OF 1240 ***

      // Wavefunction(s) for diagram number 1240
      // (none)

      // Amplitude(s) for diagram number 1240
      FFV1_0<W_ACCESS, A_ACCESS, CD_ACCESS>( w_fp[99], w_fp[2], w_fp[55], COUPs[1], 1.0, &amp_fp[0] );
      jamp_sv[40] += amp_sv[0];
      jamp_sv[46] -= amp_sv[0];
      jamp_sv[92] -= amp_sv[0];
      jamp_sv[116] += amp_sv[0];
...

But it has only 1122 entries in channel2iconfig (and 945 iconfig values)

madgraph4gpu/epochX/cudacpp/gg_ttggg.mad/SubProcesses/P1_gg_ttxggg/coloramps.h

Line 32 in 606ee3b

__device__ constexpr int channel2iconfig[1122] = { // note: a trailing comma in the initializer list is allowed

  // Map channel to iconfig (e.g. "iconfig = channel2iconfig[channelId - 1]": input index uses C indexing, output index uses F indexing)
  // Note: iconfig=-1 indicates channels/diagrams with no associated iconfig for single-diagram enhancement in the MadEvent sampling algorithm (presence of 4-point interaction?)
  // This array has N_diagrams elements, but only N_config <= N_diagrams valid values (iconfig>0)
  __device__ constexpr int channel2iconfig[1122] = { // note: a trailing comma in the initializer list is allowed
        1, // CHANNEL_ID=1     i.e. DIAGRAM=1     --> ICONFIG=1
        2, // CHANNEL_ID=2     i.e. DIAGRAM=2     --> ICONFIG=2
       -1, // CHANNEL_ID=3     i.e. DIAGRAM=3     --> ICONFIG=-1 (diagram with no associated iconfig for single-diagram enhancement)
        3, // CHANNEL_ID=4     i.e. DIAGRAM=4     --> ICONFIG=3
...
      942, // CHANNEL_ID=1119  i.e. DIAGRAM=1119  --> ICONFIG=942
      943, // CHANNEL_ID=1120  i.e. DIAGRAM=1120  --> ICONFIG=943
      944, // CHANNEL_ID=1121  i.e. DIAGRAM=1121  --> ICONFIG=944
      945, // CHANNEL_ID=1122  i.e. DIAGRAM=1122  --> ICONFIG=945
  };

  // Map iconfig to the mask of allowed colors (e.g. "colormask = icolamp[iconfig - 1]": input index uses C indexing)
  // This array has N_config <= N_diagrams elements
  __device__ constexpr bool icolamp[945][120] = { // note: a trailing comma in the initializer list is allowed
    { false,  true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false,  true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false,  true, false, false, false, false, false,  true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false,  true, false, false, false, false, false,  true, false, false, false, false, false,  true, false,  true, false, false, false,  true, false,  true, false,  true,  true,  true, false, false, false, false, false,  true, false, false, false, false, false,  true, false,  true, false, false, false, false, false, false, false, false, false }, // ICONFIG=1     <-- CHANNEL_ID=1

Now, all the work we did recently seemed to have calrified this point. But now the numbers do not add up

• There seem indeed to be 1240 diagrams (otherwise we would not have wavefunctions for them?)
• And there seem to be 945 iconfig values (icolamp is also the same number of entries in fortran coloramps.inc)
• But then what is 1122????

Rephrasing: is this a bug in the code generation of channel2iconfig?

Note, I had noticed something potentially related in the python handling here... #910

Any suggestion?
Thanks
Andrea

[oliviermattelaer]

So in itself they are no issue here.

Indeed they are 1240 diagrams and 945 channel and yes none of the diagram above 1122 are associated to a channel (this is normal since they all have a four point vertex).
So no conceptual problem.

The only potential issue is how channel2iconfig is potentially called and if number larger than 1122 are checked.
My understanding of the code make me think that this should not happen within a real life example. Did you face such case?

[valassi]

So in itself they are no issue here.

Indeed they are 1240 diagrams and 945 channel and yes none of the diagram above 1122 are associated to a channel (this is normal since they all have a four point vertex). So no conceptual problem.

Hi Olivier thanks :-)

Ok so I will just clean up the comments in the code here and there.

The only potential issue is how channel2iconfig is potentially called and if number larger than 1122 are checked. My understanding of the code make me think that this should not happen within a real life example. Did you face such case?

Well here what I was trying to do was to create tests (in runTest.cpp) that loop through many different channels.

I had a bug #920 in how I implemented that. Essentially I have a snippet of code that loops through diagrams until it finds iconfig in channel2iconfig that matches a given iconfig (this is because I need the inverse mapping). My bug was that I was starting at 1 not at 0 (ah, Fortran and C indexing...). So I was never getting out of the loop. At some point I had a diagram number above 1122 and below 1240, and I was looking for it in the channel2iconfig array, but this stops at 1122, so it was giving a segfault. And there I got worried because I did not understand if this was 'normal' or not.

In real life this should not happen. But for good sanity I will add some sanity checks when channel2iconfig is accessed, that the indexes isnide it are within an expected range. I think that getting an internal error assert is better (for users and developers) than getting a segfault. Sanity checks are situations that by definition should nt happen, but development mistakes happen (like my idiagram=1)...

I will keep this open until I implement the sanity checks. Then I will also close #910, which is essentially the same thing

[valassi]

Thanks again Olivier. I added some sanity checks, also discussed in #910.

There are indeed different numbers, which I called nchannels and ndiagrams in the code, in addition to nconfig

• ndiagrams is all diagrams
• nchannels is the first diagrams, including some with SDE, while the last diagrams have no SDE (nchannels <=ndiagrams)
• nconfig is a sparse set inside nchannels, excluding those with no SDE (nconfig <= nchannels)

Closing