master_june24: fbridgesequence_nomultichannel is not used

[valassi]

Another issue introduced in #830 and being reviewed in #882.

This is very much related to (but different from) issue #892 (unclear distinction between channelid null pointers and channeid=0 values).

When #830 was being developed, I was asked to create a new fbridgesequence_nomultichannel function call. I completed this in PR #796, which also included the calling of the new function in auto_dsig1.f,

In the #830 that was merged in master_june24, this function is not called. Comparing master to 8e312bc (which is my first commit in WIP PR #882, where I regenerated all processes using 830 CODEGEN), this gives

git diff --no-ext-diff upstream/master 8e312bc02 auto_dsig1.f
...
-        IF ( FIRST ) THEN ! exclude first pass (helicity filtering) from timers (#461)
-          CALL FBRIDGESEQUENCE_NOMULTICHANNEL( FBRIDGE_PBRIDGE, ! multi channel disabled for helicity filtering
-     &      P_MULTI, ALL_G, HEL_RAND, COL_RAND, OUT2,
-     &      SELECTED_HEL2, SELECTED_COL2 )
+        IF ( FIRST ) THEN  ! exclude first pass (helicity filtering) from timers (#461)
+          CALL FBRIDGESEQUENCE(FBRIDGE_PBRIDGE, P_MULTI, ALL_G,
+     &      HEL_RAND, COL_RAND, 0, OUT2,
+     &      SELECTED_HEL2, SELECTED_COL2 ) ! 0: multi channel disabled for helicity filtering
...
-          CALL FBRIDGESEQUENCE_NOMULTICHANNEL( FBRIDGE_PBRIDGE, ! multi channel disabled
-     &      P_MULTI, ALL_G, HEL_RAND, COL_RAND, OUT2,
-     &      SELECTED_HEL2, SELECTED_COL2 )
+          CALL FBRIDGESEQUENCE(FBRIDGE_PBRIDGE, P_MULTI, ALL_G,
+     &      HEL_RAND, COL_RAND, 0, OUT2,
+     &      SELECTED_HEL2, SELECTED_COL2 ) ! 0: multi channel disabled
...
           CALL FBRIDGESEQUENCE(FBRIDGE_PBRIDGE, P_MULTI, ALL_G,
-     &      HEL_RAND, COL_RAND, CHANNEL, OUT2,
+     &      HEL_RAND, COL_RAND, CHANNELS(1), OUT2,
      &      SELECTED_HEL2, SELECTED_COL2 ) ! 1-N: multi channel enabled
...
           CALL FBRIDGESEQUENCE(FBRIDGE_PBRIDGE, P_MULTI, ALL_G,
-     &      HEL_RAND, COL_RAND, CHANNEL, OUT2,
+     &      HEL_RAND, COL_RAND, CHANNELS(1), OUT2,
      &      SELECTED_HEL2, SELECTED_COL2 ) ! 1-N: multi channel enabled

[PS I just edited the above code snippet to add the last four lines and show CHANNELS(1), which looks strange, see #916]

Note that fbridge.cc was changed as follows, I will cross check this after using fbridgesequence_nomultichannel

 git diff --no-ext-diff upstream/master 8e312bc02 ../fbridge.cc
...
diff --git a/epochX/cudacpp/gg_tt.mad/SubProcesses/fbridge.cc b/epochX/cudacpp/gg_tt.mad/SubProcesses/fbridge.cc
index 8a5b8be9c..5b4f06db5 100644
--- a/epochX/cudacpp/gg_tt.mad/SubProcesses/fbridge.cc
+++ b/epochX/cudacpp/gg_tt.mad/SubProcesses/fbridge.cc
@@ -79,7 +79,7 @@ extern "C"
    * @param gs the pointer to the input Gs (running QCD coupling constant alphas)
    * @param rndhel the pointer to the input random numbers for helicity selection
    * @param rndcol the pointer to the input random numbers for color selection
-   * @param channelId the pointer to the input Feynman diagram to enhance in multi-channel mode if 1 to n (disable multi-channel if 0)
+   * @param channelIds the pointer to the input Feynman diagram to enhance in multi-channel mode if 1 to n (disable multi-channel if 0)
    * @param mes the pointer to the output matrix elements
    * @param selhel the pointer to the output selected helicities
    * @param selcol the pointer to the output selected colors
@@ -89,7 +89,7 @@ extern "C"
                          const FORTRANFPTYPE* gs,
                          const FORTRANFPTYPE* rndhel,
                          const FORTRANFPTYPE* rndcol,
-                         const unsigned int* pchannelId,
+                         const unsigned int* pchannelIds,
                          FORTRANFPTYPE* mes,
                          int* selhel,
                          int* selcol )
@@ -99,11 +99,11 @@ extern "C"
 #ifdef MGONGPUCPP_GPUIMPL
     // Use the device/GPU implementation in the CUDA library
     // (there is also a host implementation in this library)
-    pbridge->gpu_sequence( momenta, gs, rndhel, rndcol, ( pchannelId ? *pchannelId : 0 ), mes, selhel, selcol );
+    pbridge->gpu_sequence( momenta, gs, rndhel, rndcol, pchannelIds, mes, selhel, selcol );
 #else
     // Use the host/CPU implementation in the C++ library
     // (there is no device implementation in this library)
-    pbridge->cpu_sequence( momenta, gs, rndhel, rndcol, ( pchannelId ? *pchannelId : 0 ), mes, selhel, selcol );
+    pbridge->cpu_sequence( momenta, gs, rndhel, rndcol, pchannelIds, mes, selhel, selcol );
 #endif
   }

[oliviermattelaer]

Huum, I'm not sure to understand why we would deactivate the multi-channel for the helicity filtering...
I guess that the real question is what is the workflow on how this is used.
Sorry to drag the issue slightly outside the original direction but I think that this is an important point.

In any case, deactivating will never be wrong (just maybe not optimal)

Cheers,

Olivier

[valassi]

Huum, I'm not sure to understand why we would deactivate the multi-channel for the helicity filtering...

Hi Olivier, thanks.

We have ALWAYS been deactivating multichannel on helicity filtering so far, and I am not proposing to change that.

What has changed is HOW this must be done. I suspect that the 830 way of doing it is wrong (I am debugging various issues in madevent tests). I think this should be done with that FBRIDGESEQUENCE_NOMULTICHANNEL function. In any case, this function was created for the channelid (I was asked to create it for that!), it exists, so I will just put it back

[oliviermattelaer]

We have ALWAYS been deactivating multichannel on helicity filtering so far, and I am not proposing to change that.

I know, but the question still remains (I can open another issue on that if you prefer).

In Fortran, without helicity-filtering, the multi-channel is activated when doing such filtering.
So deactivating it in cpp is a change of behavior compare to Fortran.
Even with helicity recycling, I'm not sure if we do deactivate the multi-channel (but we make sure that each PS point is using a different channel in that case).

And this issue is a good opportunity to (re)think if we really need to deactivate it or not.

[valassi]

I know, but the question still remains (I can open another issue on that if you prefer).

In Fortran, without helicity-filtering, the multi-channel is activated when doing such filtering.

Thanks. Let's take this as a different issue, to address AFTER fixing all these channelids and master_june24 issues. I think I have enough on my plate sorry. To debug the many issues I already have, I prefer to have minimal changes. This is one that I would do later. Ok? Thanks

[valassi]

Thanks Olivier for filing #915.

I have fixed this #914 here b97ef72
Now the results from madevent (what is printed out as channelid array) is better, and I get a cross section (ONLY after fixing ALSO #916)

This will be in MR #882. Closing.