Remove (or simplify) ifdefs for MULTICHANNEL

[valassi]

I want to simplify a bit the code structure, in particular remove the ifdefs for multichannel.

Essentially, calculate_wavefunctions has two different signatures if multichannel is enabled or disabled. This makes CPPProcess.cc even heavier in places

#ifdef MGONGPU_SUPPORTS_MULTICHANNEL
        constexpr unsigned int channelId = 0; // disable single-diagram channel enhancement
        calculate_wavefunctions( ihel, allmomenta, allcouplings, allMEs, channelId, allNumerators, allDenominators, ievt00 );
#else
        calculate_wavefunctions( ihel, allmomenta, allcouplings, allMEs, ievt00 );
#endif

I essentially NEVER use or test the option with MGONGPU_SUPPORTS_MULTICHANNEL not defined. I even realised now (I had completely forgotten!) that in the .sa mode I build with it undefined (see #473), but I no longer build it ir test it since a while.

I find it much easier/better to do the following:

• keep always the ful API with channelid, numerators, denominators
• internally, if MGONGPU_SUPPORTS_MULTICHANNEL is not enabled, ignore those parameters (similar to what I do now for channelid=0)

One of the main differences is that numerators and denominator arrrays will not be allocated at all.

I will give it a try

[valassi]

I am getting a slightly different idea about this.

1. What I really dislike is that sigmaKin et al have different interfaces depening on the ifdef. So I would like to keep always the API where multichannel is possible (whether if thst is used or not)
2. One of the main advantages of removing (or ifdeffing away) some parts of the code in non multichannel mode is speed. In CPPProcess.cc the various numerator/denominator checks against channelId should be skipped altogether for instance.
3. I started to think about this because in no multichannel mode I do not even write out coloramps - so it is silly to keep the ifdefs if not all the code is there.

What I think would be cleaner is the following

1. Keep always the same API whether MGONGPU_SUPPORTS_MULTICHANNEL is supported or not. However pass null pointers for numerators and denominators and pass 0 for channelId if the ifdef is false. Optionally add a sanity check in all functions that channelId is 0 (if it is not zero you should throw because you are unable to respect the role of the function).
2. Keep the speed by ifdeffing away the channelId part at every Feynman diagram in CPPProcess.cc if MGONGPU_SUPPORTS_MULTICHANNEL is false. The point is that you can disable multichannel at runtime by using channel 0, but in that case it is faster to disable it at build time by unsetting MGONGPU_SUPPORTS_MULTICHANNEL. This should be as fast as disabling it at code generation time (i.e. not generating the code at all, see point 4).
3. Do generate sa and mad using the same multichannel=true, including coloramps.
4. Eventually, if really needed we can also disable multichannel at generation time (ie remove all the ifdeffed sections). But this is very complex and probably unnecessary.

[valassi]

See also the discussion in #473.

From that discussion, the whole idea of continuing to generate the .sa directories was that it is a different way of generating

• xxx.sa uses only cudacpp in standaone mode
• xxx.mad uses madevent plus "second exporter"
  So I guess that I wanted to make sure that whatever is created from the standalone code makes sense.

Now, multichannel is relevant here because, IIUC from #473, when I am not in madevent, I simply CANNOT generate the multichannel info. So I need to make sure that the code generated that way builds too.

That said, this still allows me to generate code with multichannel and build it with multichannel disabled. Again, multichannel can be disabled at three level
1- code generation (eg if you do not include madevent)
2- code build, by unsetting an ifdef on code generated with multichannel
3- code runtime, by channelid=0 on code generated and built with multichannel

The whole point of this #568 in a way is to allow 2 (and to some extent 3) by using the same APIs in sigmakin.

Note that the channelid sections are already disabled after each Feynmany diagram, so this does not need to be done

madgraph4gpu/epochX/cudacpp/gg_tt.mad/SubProcesses/P1_gg_ttx/CPPProcess.cc

Line 239 in 3780502

#ifdef MGONGPU_SUPPORTS_MULTICHANNEL

#ifdef MGONGPU_SUPPORTS_MULTICHANNEL
      if( channelId == 1 ) numerators_sv += cxabs2( amp_sv[0] );
      if( channelId != 0 ) denominators_sv += cxabs2( amp_sv[0] );
#endif

Rephrasing: the only thing I still want to do is to use the same API (same with and without multichannel, ie always keep channelid and numerators/denominators, both in calculate wavefunction and sigmakin) to simplify the code readability. Will be done in a MR after random choice of color.

[valassi]

I am reviewing old issues.

This is very much related to what I tried yesterday in ce57dda for MR #796. Copying @roiser and @oliviermattelaer for info,

My conclusions from that work is, it is impossible (or not very practical) to remove the MULTICHANNEL ifdefs. So this issue #568 can be closed.

As mentioned in MR #796 there are thee use cases
a- multichannel code, with channelid>0 (presently a scalar, eventuallay an array via a pointer)
b- multichannel code, with channelid=0 (presently a scalar, eventually a pointer=0 in cudacpp and a different function in fortran, i.e. this PR)
c- no-multichannel code (no coloramps.h), is pure standalone generation

The reason why the ifdefs cannot be removed is use case c: if madevent is not included because codegen is standalone, then there is no coloramps.h, and it simply makes no sense to have color choice code. In that case, it seems just easier to bypass numerator/denominator pointers completely, hence a different signature of some functions.

This could still be reviewed eventually, but for the moment I'd keep it as is (as it will be after MR #796) Closing.