wrong assert in cudacpp plugin (and test code generation for pptt)

[oliviermattelaer]

hi,

I do have the following crash

  File "/Users/omattelaer/Documents/workspace/convert_to_git/git-mg5amcnlo/PLUGIN/CUDACPP_SA_OUTPUT/model_handling.py"\
, line 1187, in get_matrix_element_calls
    res = self.super_get_matrix_element_calls(matrix_element, color_amplitudes)
  File "/Users/omattelaer/Documents/workspace/convert_to_git/git-mg5amcnlo/PLUGIN/CUDACPP_SA_OUTPUT/model_handling.py"\
, line 1176, in super_get_matrix_element_calls
    scoeff = PLUGIN_OneProcessExporter.coeff(*coeff) # AV
  File "/Users/omattelaer/Documents/workspace/convert_to_git/git-mg5amcnlo/PLUGIN/CUDACPP_SA_OUTPUT/model_handling.py"\
, line 992, in coeff
    assert(False)
AssertionError

when doing (from master)

generate p p > t t~; output standalone_cudacpp mytest

Is there a real reason for this assert?

[valassi]

Hi Olivier, interesting, it looks clearly wrong. I will have a look. I guess I need to generate a test pptt too as otherwise I will not see that? I am surprised I do not see the issues in the three processes I use routinely

[valassi]

I rename this to also mention "and test code generation for pptt" - the reason why I never had the issue reported by Olivier is that I never tried pptt, I gues?

[valassi]

Thanks Olivier, this was easily confirmed. I will work on PR #340 about this.

I just realise I have no idea what the pptt code should look like. If I take the default madgraph without my plugin (say 270gou which is what I am based on for now), that was working for you initially and was producing code that made sense?

Thanks Andrea

[valassi]

Hi @oliviermattelaer

this specific issue is fixed easily: I just disabled the "assert(False)". I think that I had added that to understand if/when thi smethod "coeff" was used at all. I found that it is not used in eemumu or ggtt, but it it is used in uutt (or in the uutt within pptt).
2876844

There is now however a more fundamental issue with pptt, namely the problem of nprocesses>1 (#272). After fixing the assert, code generation succeeds but the build fails because of that nprocesses. I checked that the uutt standalone and the uutt within pptt differ in the following way for instance:

/data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp> diff -r pp_tt.auto/ uu_tt.auto/
...
diff -r pp_tt.auto/SubProcesses/P1_Sigma_sm_uux_ttx/CPPProcess.cc uu_tt.auto/SubProcesses/P1_Sigma_sm_uux_ttx/CPPProcess.cc
...
502c497
<     const int denominators = 36,36; // FIXME: assume process.nprocesses == 1 for the moment (eventually denominators[nprocesses]?)
---
>     const int denominators = 36; // FIXME: assume process.nprocesses == 1 for the moment (eventually denominators[nprocesses]?)

From our discussions, I understand that this is because "uutt" within pptt is not only "uu" proper, but also some other combinations of quarks (I guess bbtt is the very different case?). Anyway, what I mean is that the ggtt within pptt and the ggtt standalone instead are essentially the same code, so it is really the "uutt" part which is different. I will have a look.

[valassi]

Hi Olivier, as discussed this afternoon, I have fixed the assert in #340, which I am about to merge, but I am reassigning to you the fix of the "nprocesses=2" issue. This is now in #343.

Closing this as fixed by PR #340.