No cross section in SUSY gg_t1t1 log file

[valassi]

In PR #824 I fixed SUSY codegen, builds and internal tests cuda/cpp.
But now I ALSO added the test comparing to fortran and this fails

In tmad/logs_susyggt1t1_mad/log_susyggt1t1_mad_d_inl0_hrd0.txt

*** (2-none) EXECUTE MADEVENT_CPP x1 (create events.lhe) ***
--------------------
CUDACPP_RUNTIME_FBRIDGEMODE = (not set)
CUDACPP_RUNTIME_VECSIZEUSED = 8192
--------------------
8192 1 1 ! Number of events and max and min iterations
0.000001 ! Accuracy (ignored because max iterations = min iterations)
0 ! Grid Adjustment 0=none, 2=adjust (NB if = 0, ftn26 will still be used if present)
1 ! Suppress Amplitude 1=yes (i.e. use MadEvent single-diagram enhancement)
0 ! Helicity Sum/event 0=exact
1 ! Channel number (1-N) for single-diagram enhancement multi-channel (NB used even if suppress amplitude is 0!)
--------------------
Executing ' ./build.none_d_inl0_hrd0/madevent_cpp < /tmp/avalassi/input_susyggt1t1_x1_cudacpp > /tmp/avalassi/outpu
t_susyggt1t1_x1_cudacpp'
 [OPENMPTH] omp_get_max_threads/nproc = 1/4
 [NGOODHEL] ngoodhel/ncomb = 4/4
 [XSECTION] VECSIZE_USED = 8192
 [XSECTION] MultiChannel = TRUE
 [XSECTION] Configuration = 1
 [XSECTION] ChannelId = 2
 [XSECTION] ERROR! No cross section in log file:
   /tmp/avalassi/output_susyggt1t1_x1_cudacpp
   ...
xqcutij # 3>     0.0     0.0
 RESET CUMULATIVE VARIABLE
 NGOODHEL =           4
 NCOMB =           4
 MULTI_CHANNEL = TRUE
 CHANNEL_ID =           2
 RESET CUMULATIVE VARIABLE
        4096  points passed the cut but all returned zero
 therefore considering this contribution as zero
 Deleting file events.lhe

[oliviermattelaer]

After PR #850, the code does provide a cross-section (even if the statement might be machine specific).
But in any case the cross-section does not match
(1.098 for fortran (LTS is at 1.101) versus 1.357 for C++)
So still need investigation

[valassi]

Hi @oliviermattelaer thanks for the patch in PR #850! This seems to fix the other issue #825 on cross section mismatch for susy_gg_tt (pending investgations in other processes).

After PR #850, the code does provide a cross-section (even if the statement might be machine specific). But in any case the cross-section does not match (1.098 for fortran (LTS is at 1.101) versus 1.357 for C++) So still need investigation

However I am puzzled by your statement. As mentioned in #850 (comment) the susy_gg_t1t1 test still gives no cross section in my test. Can you confirm you see a cross section?

And/or can you try to run this script (from epochX/cudacpp) and see what it gives? (Do a git diff afterwards)

./tmad/teeMadX.sh -susyggt1t1 +10x

I would be curious to see if in your environment this succeeds...

Thanks!
Andrea

[oliviermattelaer]

actually none of the script
./tmad/teeMadX.sh
are working on my laptop... (even eemumu)
they all crashed due to the google test/cmake issue

So yes this is not working but not real information to take away.
But I do confirm that running "as an user" provides a non zero (but wrong) cross-section.
So I will start by investigate that missmatch and then hopefully this will fix your issue too (or we will need to iterate)

I have check subset of diagram (physical meaning not being the point) --cross means agreement--:

• g g > t1 t1~ / t1 t2 g : (1 diagram) 1.371(LTS) vs 1.373 (CPP)
• g g > g > t1 t1~ / t1 t2 : (1 diagram) 0.2134 (LTS) vs 0.2132 (CPP)
• g g > t1 t1~ / t1 t1: (2 diagram, the same as the two above) 1.585 (LTS) vs 1.585 (fortran) vs 1.346 (CPP)
• g g > t1 t1~: (6 diagram) 1.101 (LTS) vs 1.098 (Fortran) vs 1.357 (CPP)

So it seems that the issue is quite subtle here since each diagram "alone" works but not when combined.
I'm looking for a wrong phase for the moment. But I do not have any clear indication of the issue behind the above point.

[oliviermattelaer]

@roiser
Looks like this could be something for you to investigate on the ordering of the coupling
here is the value that I got for the coupling in fortran

c4 = (0, 1.27)
c_3v = (-1,12,0)
c_3s = (0, -1.12) 

(the exact value are not important since they are all running)
here is the value that I have for the CPP code:

c4= (-1.14, 0)
c_3v = (0, 1.12)
c_3s = (0, -1.14)

So in fortran I do have

c_3s = i c_3v

while in CPP

c_3s = i c_4

Which sounds like an ordering issue.
Second issue is that the coupling seems to have a phase between fortran and cpp (which is not really problematic since global phase disapear) but if you can check that you have not a swap of real/imaginary component at the same time.

Thanks,

Olivier

[valassi]

actually none of the script
./tmad/teeMadX.sh
are working on my laptop... (even eemumu)
they all crashed due to the google test/cmake issue

Hi Olivier, thanks. Two points

• one, tmad scripts should not depend on gtest at all, can you confirm? (only the other tput scripts run gtest)
• two, if there is an issue on your laptop with gtest, can we try to fix it?... let me know what is the issue, open a ticket, maybe i can have a look (and does it work on your desktop or not? the one where in principle I have access)

[valassi]

@oliviermattelaer I tried to 'run as a user'. I still get a crash. From our gpucpp branch (HEAD detached at f9f957918), inside ./bin/mg5_aMC I do

set stdout_level DEBUG
set zerowidth_tchannel F
import model MSSM_SLHA2
generate g g > t1 t1~
output madevent_simd susy_gg_t1t1.mad --hel_recycling=False --vector_size=32 
launch

Except for launch, this is what is used to generate the code in teh repo (see file https://github.com/madgraph5/madgraph4gpu/blob/master/epochX/cudacpp/susy_gg_t1t1.mad/mg5.in).

With default parameters for launch, this eventually gives me

...
Using random number seed offset = 21
INFO: Running Survey 
Creating Jobs
Working on SubProcesses
[Errno 2] No such file or directory: '/data/avalassi/GPU2023/madgraph4gpuX/MG5aMC/mg5amcnlo/susy_gg_t1t1.mad/SubProcesses/P1_gg_t1t1x/Hel/selection'
INFO:     P1_gg_t1t1x  
Building madevent in madevent_interface.py with 'cpp' matrix elements
INFO:  Idle: 1,  Running: 1,  Completed: 0 [ current time: 13h22 ] 

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7f335fa23860 in ???
#1  0x7f335fa22a05 in ???
#2  0x7f335f654def in ???
#3  0x7f33601722d5 in ???
#4  0x7f3360044575 in ???
#5  0x7f336016fef1 in ???
#6  0x7f3360173d5d in ???
#7  0x7f3360179363 in ???
#8  0x42044f in ???
#9  0x42158d in ???
#10  0x421de9 in ???
#11  0x4224c0 in ???
#12  0x432c88 in ???
#13  0x41fba4 in ???
#14  0x41ffe5 in ???
#15  0x7f335f63feaf in ???
#16  0x7f335f63ff5f in ???
#17  0x4036b4 in ???
#18  0xffffffffffffffff in ???
rm: cannot remove 'results.dat': No such file or directory
ERROR DETECTED
INFO:  Idle: 0,  Running: 1,  Completed: 1 [  0.19s  ] 
INFO:  Idle: 0,  Running: 0,  Completed: 2 [  0.21s  ] 
INFO: End survey 
refine 10000
Creating Jobs
INFO: Refine results to 10000 
INFO: Generating 10000.0 unweighted events. 
Error when reading /data/avalassi/GPU2023/madgraph4gpuX/MG5aMC/mg5amcnlo/susy_gg_t1t1.mad/SubProcesses/P1_gg_t1t1x/G3/results.dat
Command "generate_events run_01" interrupted with error:
Exception : Reported error: End code 136.0 
...

Note: SIGFPE: Floating-point exception - erroneous arithmetic operation. is what I had seen also in gqttq once, then it had disappeared, see #845. Most likely here it is staying. I guess this is what should be debugged.

I am very puzzled that you do not see it. Maybe it is because you are on a Mac? Can you try on a Linux box please?

Thanks
Andrea

[oliviermattelaer]

So yes on our haswell node of the cluster (since this maybe hardware specific) it does crash:

Backtrace for this error:
#0  0x7ff7388beb4f in ???
#1  0x7ff739888bc9 in _ZN9mg5amcCpu8sigmaKinEPKdS1_S1_S1_PdjS2_S2_PiS3_i._omp_fn.0
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/CPPProcess.cc:1155
#2  0x7ff7398326e5 in GOMP_parallel
	at ../../../libgomp/parallel.c:178
#3  0x7ff739888797 in _ZN9mg5amcCpu8sigmaKinEPKdS1_S1_S1_PdjS2_S2_PiS3_i
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/CPPProcess.cc:1059
#4  0x7ff739891d0f in _ZN9mg5amcCpu23MatrixElementKernelHost21computeMatrixElementsEj
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/MatrixElementKernels.cc:115
#5  0x7ff7398944b9 in _ZN9mg5amcCpu6BridgeIdE12cpu_sequenceEPKdS3_S3_S3_jPdPiS5_b
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/Bridge.h:390
#6  0x7ff73989614f in fbridgesequence_
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/fbridge.cc:106
#7  0x42e62e in smatrix1_multi_
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/auto_dsig1.f:574
#8  0x42fd15 in dsig1_vec_
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/auto_dsig1.f:401
#9  0x430aec in dsigproc_vec_
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/auto_dsig.f:1031
#10  0x431510 in dsig_vec_
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/auto_dsig.f:327
#11  0x4449c5 in sample_full_
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/Source/dsample.f:208
#12  0x42dd22 in driver
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/driver.f:256
#13  0x42e16d in main
	at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/driver.f:301
Floating point exception (core dumped)

[valassi]

I am even more confused, but the issue I see in tmad tests is NOT a SIGFPE.

Essentially, to reproduce outside tmad tests:

• go to epochX/cudacpp/susy_gg_t1t1.mad/SubProcesses/P1_gg_t1t1x
• type make -j BACKEND=cppnone
• create the file input_susyggt1t1_x1_cudacpp:
• type ./madevent_cpp < input_susyggt1t1_x1_cudacpp

In practice:

make -j BACKEND=cppnone
cat > input_susyggt1t1_x1_cudacpp << EOF
8192 1 1 ! Number of events and max and min iterations
0.000001 ! Accuracy (ignored because max iterations = min iterations)
0 ! Grid Adjustment 0=none, 2=adjust (NB if = 0, ftn26 will still be used if present)
1 ! Suppress Amplitude 1=yes (i.e. use MadEvent single-diagram enhancement)
0 ! Helicity Sum/event 0=exact
1 ! Channel number (1-N) for single-diagram enhancement multi-channel (NB used even if suppress amplitude is 0!)
EOF
./madevent_cpp < input_susyggt1t1_x1_cudacpp

What I get is an error which ends like this

...
Running Configuration Number:    1
 Not subdividing B.W.
 Attempting mappinvarients           1           4
 Determine nb_t
 T-channel found:            0
 Completed mapping           4
 about to integrate            4        8192           1           1           4           1
 Keeping grid fixed.
  4 dimensions   8192 events  4 invarients  1 iterations  1 config(s),  (0.99)
 Using h-tuple random number sequence.
 Error opening grid
 Using Uniform Grid!          16
 Using uniform alpha   1.0000000000000000     
 Grid defined OK
 Masses: 0.000E+00 0.000E+00 0.400E+03 0.400E+03
 Set CM energy to      13000.00
 Mapping Graph           1  to config           1
 Determine nb_t
 T-channel found:            0
 Transforming s_hat 1/s            3   3.7807079264437879E-003   638939.63956899999        168999999.99999997     
 Error opening symfact.dat. No permutations used.
Using random seed offsets     1 :      1
  with seed                   21
 Ranmar initialization seeds       27402        9395
  Particle       3       4
      Et >     0.0     0.0
       E >     0.0     0.0
     Eta <    -1.0    -1.0
   xqcut:      0.0     0.0
d R # 3  >    -0.0     0.0
s min # 3>     0.0     0.0
xqcutij # 3>     0.0     0.0
 RESET CUMULATIVE VARIABLE
 NGOODHEL =           4
 NCOMB =           4
 MULTI_CHANNEL = TRUE
 CHANNEL_ID =           2
 RESET CUMULATIVE VARIABLE
        4096  points passed the cut but all returned zero
 therefore considering this contribution as zero
 Deleting file events.lhe

[valassi]

So yes on our haswell node of the cluster (since this maybe hardware specific) it does crash:

Thanks @oliviermattelaer ! We were writing at the same time.

Weird, so MANY issues

• (this original No cross section in SUSY gg_t1t1 log file #826) if I just run madevent manually, I get an early exit of madevent, no cross section (reproducer above), but no SIGFPE crash
• from launch, it crashes with some SIGFPE, but apparently only on Linux...

(I will not do much more before I leave on holiday in a few days, hopefully you'll find out more in the meantime! thanks)

[valassi]

In practice, go to epochX/cudacpp/susy_gg_t1t1.mad/SubProcesses/P1_gg_t1t1x and then

make -j BACKEND=cppnone
cat > input_susyggt1t1_x1_cudacpp << EOF
8192 1 1 ! Number of events and max and min iterations
0.000001 ! Accuracy (ignored because max iterations = min iterations)
0 ! Grid Adjustment 0=none, 2=adjust (NB if = 0, ftn26 will still be used if present)
1 ! Suppress Amplitude 1=yes (i.e. use MadEvent single-diagram enhancement)
0 ! Helicity Sum/event 0=exact
1 ! Channel number (1-N) for single-diagram enhancement multi-channel (NB used even if suppress amplitude is 0!)
EOF
./madevent_cpp < input_susyggt1t1_x1_cudacpp

@oliviermattelaer can you try also this one for curiosity please? both from linux and mac... thanks

[valassi]

Backtrace for this error:
#0 0x7ff7388beb4f in ???
#1 0x7ff739888bc9 in _ZN9mg5amcCpu8sigmaKinEPKdS1_S1_S1_PdjS2_S2_PiS3_i._omp_fn.0
at /auto/home/users/o/m/omatt/mg5amcnlo/PROC_MSSM_SLHA2_0/SubProcesses/P1_gg_t1t1x/CPPProcess.cc:1155
#2 0x7ff7398326e5 in GOMP_parallel
at ../../../libgomp/parallel.c:178

And @oliviermattelaer other question, what is at this line? CPPProcess.cc:1155

Thanks Andrea

PS In my case 1154,55,56 are

#if defined MGONGPU_CPPSIMD
            const bool okcol = allrndcol[ievt] < ( targetamp[icolC][ieppV] / targetamp[ncolor - 1][ieppV] );
#else

[valassi]

Anyway, I confirm that I also reproduce "SIGFPE: erroneous arithmetic operation" from the repo

• go to epochX/cudacpp/susy_gg_t1t1.mad/SubProcesses/P1_gg_t1t1x and then

./bin/generate_events run01

I have no idea why I get a SIGFPE crash in this mode and I get an empty cross section but no crash if I run madevent manually

[oliviermattelaer]

Hi,

yes the line is indeed:

const bool okcol = allrndcol[ievt] < ( targetamp[icolC][ieppV] / targetamp[ncolor - 1][ieppV] );

and no surprise, targetamp[ncolor-1] is here zero...

 ievt 0 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 1 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 2 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 3 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 4 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 5 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 6 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 7 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 8 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 9 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 10 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 11 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 12 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 13 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 14 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 15 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 0 , ieppV, 0 , ncolor 2, max 3.101819
 ievt 1 , ieppV, 1 , ncolor 2, max 3.336748
 ievt 2 , ieppV, 2 , ncolor 2, max 2.629749
 ievt 3 , ieppV, 3 , ncolor 2, max 3.350298
 ievt 4 , ieppV, 0 , ncolor 2, max 4.813758
 ievt 5 , ieppV, 1 , ncolor 2, max 2.866929
 ievt 6 , ieppV, 2 , ncolor 2, max 2.657539
 ievt 7 , ieppV, 3 , ncolor 2, max 4.112587
 ievt 8 , ieppV, 0 , ncolor 2, max 8.225509
 ievt 9 , ieppV, 1 , ncolor 2, max 3.152658
 ievt 10 , ieppV, 2 , ncolor 2, max 2.698144
 ievt 11 , ieppV, 3 , ncolor 2, max 2.709947
 ievt 12 , ieppV, 0 , ncolor 2, max 2.629970
 ievt 13 , ieppV, 1 , ncolor 2, max 2.769736
 ievt 14 , ieppV, 2 , ncolor 2, max 2.622860
 ievt 15 , ieppV, 3 , ncolor 2, max 6.583436
 ievt 0 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 1 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 2 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 3 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 4 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 5 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 6 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 7 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 8 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 9 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 10 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 11 , ieppV, 3 , ncolor 2, max 0.000000
 ievt 12 , ieppV, 0 , ncolor 2, max 0.000000
 ievt 13 , ieppV, 1 , ncolor 2, max 0.000000
 ievt 14 , ieppV, 2 , ncolor 2, max 0.000000
 ievt 15 , ieppV, 3 , ncolor 2, max 0.000000

What surprise/interest me is that it is 0 (or not) for a full block of 16 events... which might be a symfact related issue...
And "YES" if I remove the symmetric channel this never happens ...

[valassi]

Hi Andrea,

I think that the code behaves strangely due to a out of bound issue (in the CPP part). That out of bound can corrupt some memory making the code (even the fortran part) leading to some random crash (compiler flag and machine specific way of crashing -> not reproducible). Since I/We have identified one of such issue, I think the first thing that we should do is to fix that one and then re-investigate the other issue (For me #852 fixes all crashing issue).

So for me, the priority is to merge #852. I will work on it now to include more comment on it as you want. Then after that my priority would be to understand which variable is used un-identified from valgrind since this will be a good hint from where the next issue is.

Hi Olivier, thanks for the message and sorry for not replying on this before.

Just replying here to try and summarise the various directions of work that this issue 826 triggered somehow. For me this was the work of this last (very busy) week.

• About 'for me 852 fixes all issues': as discussed at/after the meeting this week, this was not the case for me. In particular, one specific crash was in rotxxx (tmad test crashes in rotxxx (SIGFPE erroneous arithmetic operation) #855): you had said that 852 fixed it for you, but I showed ((DO NOT MERGE: for reference only) Further tests of Olivier's "fix_826" branch PR 852 #870) that it does not. Instead, I fixed this rotxxx crash by adding 'volatile' in fortran code (Fix SIGFPE crash (855) in rotxxx by adding volatile in aloha_functions.f #857 and Add 'volatile' in function rotxxx to prevent crashes in optimized code  mg5amcnlo/mg5amcnlo#113, both merged)

• (En passant, during this week I added tmad tests to the CI, so many if these issues - not all - can now more easily be seen there, extend testsuite CI (split codegen from build/test, execute tests for many fptypes, add tmad tests) #794, merged)

• About your 852, this is certainly necessary to fix some iconfig-channel mappings that are relevant to fix MAJOR ISSUE: color mismatch fortran/cpp in LHE file for iconfig 104 in SM gg_ttgg (channel/iconfig mapping AND icolamp issues) #856 (LHE color mismatch). But by itself it is not enough: so I included that in Fixes for iconfig-channel mappings in coloramps.h (obsolete, will be closed) #873, which also depends on Fix icolamp in export_cpp.py (against gpucpp_june24?) mg5amcnlo/mg5amcnlo#115). I agree that now merging these is the highest priority. I would merge mg5amcnlo 115 and then 873, and this automatically merges your 852 in master. If this also helps to fix some segfaults, so much the better (I do not see that).

• There is another crash Intermittent FPE "erroneous arithmetic operation" in gqttq tmad test (for cpp512z with FPTYPE=f only: fix it with 'volatile') #845, in sigmakin, only for SIMD 512z with FPTYPE=f. Initially I ha dthe same impression as you, namely that it was an out of bounds, but I am quite sure that it is a SIMD optimization instead. I fixed this in Fix intermittent FPE crashes for SIMD (add volatile) and allow no-OpenMP builds #874, also to be merged. I would merge this after 873 however, as it contains it internally, so it becomes easier to review the differences.

• About the out of bound issues. As I said, I also had the impression we had some out of bounds. But then I ran many tests, and honestly I never found a segmentation fault from out of bounds: I only saw SIGFPE crashes (which are typically SIMD issues, and are fixed with volatile). I also used extensively valgrind. I found no issue in cudacpp with valgrind, but I fixed two minor issues in Workaround for unitialised goodjet in function setclscales in reweight.f mg5amcnlo/mg5amcnlo#112 and Fix memory leak in madevent_driver.f (close file dname.mg) mg5amcnlo/mg5amcnlo#110

• About this specific 826! While this triggered all the work above, none of the work above is relevant to it I think. This 826 is about a zero cross section in susy process. IIUC you and Stefan have tracked this down to a coupling issue. I reported that in Coupling ordering issue? #862 (maybe a duplicate of this No cross section in SUSY gg_t1t1 log file #826, maybe not). In any case Stefan (thanks) is working on it

• Note, this week with the work above I found yet another new problem, a cross section mismatch Cross section mismatch in pp_tt012j (P2_gu_ttxgu) in CI tmad tests - reset_cumulative_variable was called twice in fortran and once in cudacpp #872. Together with this 826, this is the only issue that will normally show up in the new CI until it is fixed (I have mechanisms to bypass the errors however if required)

Voila this seems like a good summary of this week, replying to your points above.

Summary of the todo summary

• lets merge mg5amcnlo 115 and then 873 (which will auto merge 852 too)
• then lets merge 874
• then Stefan will make a pr for this 826
• (and at some point I look at your CI proposal and at your june24 branches)

[valassi]

This specific issue 826 about a zero cross section in susy process is fixed by PR #918 (thanks @oliviermattelaer @roiser). Indeed it is caused by a couplings order #862.

Closing this as fixed by PR #918 (to be merged soon). Code regenerated in #934.

[valassi]

This is also related to #748 (xsec mismatch in gqttq, which was also due to ther order of couplings)