Problems in ggttgg lhe files after the latest upstream changes (replacing channel by iconfig in select_color)

[valassi]

Hi @oliviermattelaer (cc @roiser), I have rerun the usual tests after the upgrade to the latest mg5amcnlo upstream.

Most tests succeed, but in ggttgg I get differences in the lhe files:

In tmad/logs_ggttgg_mad/log_ggttgg_mad_d_inl0_hrd0.txt:
+ERROR! events.lhe.cpp.1 and events.lhe.ref.1 differ!
+diff /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/gg_ttgg.mad/SubProcesses/P1_gg_ttxgg/events.lhe.cpp.1 /data/avalassi/GPU2023/madgraph4gpuX/epo$
+3,4c3,4
+<          21   -1    0    0  503  502  0.00000000000E+00  0.00000000000E+00  0.13289043826E+04  0.13289043826E+04  0.00000000000E+00 0. -1.
+<          21   -1    0    0  504  503 -0.00000000000E+00 -0.00000000000E+00 -0.81223316322E+02  0.81223316322E+02  0.00000000000E+00 0. -1.
+---
+>          21   -1    0    0  505  502  0.00000000000E+00  0.00000000000E+00  0.13289043826E+04  0.13289043826E+04  0.00000000000E+00 0. -1.
+>          21   -1    0    0  502  503 -0.00000000000E+00 -0.00000000000E+00 -0.81223316322E+02  0.81223316322E+02  0.00000000000E+00 0. -1.
+6,8c6,8
+<          -6    1    1    2    0  505  0.39403209480E+02 -0.10079469096E+02  0.28578226692E+03  0.33653337532E+03  0.17300000000E+03 0. -1.
+<          21    1    1    2  504  501 -0.19269775075E+03  0.33434234480E+02  0.26595208036E+03  0.33012237159E+03  0.00000000000E+00 0. -1.
+<          21    1    1    2  505  502  0.20498361398E+02  0.29398294961E+02  0.12436578484E+03  0.12942677855E+03  0.00000000000E+00 0. -1.
+---
+>          -6    1    1    2    0  504  0.39403209480E+02 -0.10079469096E+02  0.28578226692E+03  0.33653337532E+03  0.17300000000E+03 0. -1.
+>          21    1    1    2  504  503 -0.19269775075E+03  0.33434234480E+02  0.26595208036E+03  0.33012237159E+03  0.00000000000E+00 0. -1.
+>          21    1    1    2  505  501  0.20498361398E+02  0.29398294961E+02  0.12436578484E+03  0.12942677855E+03  0.00000000000E+00 0. -1.
+54,56c54,56
+<          -6    1    1    2    0  504  0.12539878316E+03  0.25084537686E+03  0.17266798312E+03  0.37201006747E+03  0.17300000000E+03 0.  1.
+<          21    1    1    2  504  505  0.91559552940E+02 -0.56451043237E+03  0.74367925168E+03  0.93814391719E+03  0.00000000000E+00 0. -1.
+<          21    1    1    2  505  503 -0.59178509296E+01 -0.20888672560E+02  0.16637826240E+02  0.27352785287E+02  0.00000000000E+00 0.  1.
+---
+>          -6    1    1    2    0  505  0.12539878316E+03  0.25084537686E+03  0.17266798312E+03  0.37201006747E+03  0.17300000000E+03 0.  1.

I will try to have a look, but does this ring a bell, any way to interpret this?
Thanks
Andrea

[valassi]

This is from 8e09746 in MR #654

[valassi]

@oliviermattelaer I made some tests and this clearly seems to come from this one
mg5amcnlo/mg5amcnlo@0a1038d

Can you confirm that this is correct and that I should fix the GPU plugin to give the same results?

NB my understanding is that this is causing in Fortran only a change in the color assignments in LHE files?

Thanks
Andrea

[valassi]

I have created and merged a NOOP mg5amcnlo/mg5amcnlo#56 where I created a commit hash that works as-is for the current as-is gpu plugin. This will allow me to merge #654 I hope. Then this #655 will need to be fixed searately... so it stays very much open...

[oliviermattelaer]

I believe that this was the patch that was fixing the issue for ta+ ta- sample for atlas no?

[valassi]

Hi @oliviermattelaer thanks for looking at this :-)

The only ta+ ta- issue I remember (but I still need to look better at some emails) was #645, problems in CKKW. This I actually noted down as "CMS Drell Yan" (I think it was Sapta from CMS, not ATLAS, but I may be wrong). Anyway, that particular one had a fix from a different commit mg5amcnlo/mg5amcnlo@ef334c5.

Or you mean another ta+ ta- issue for ATLAS? Maybe @roiser knows better?

Anyway, the commit which caused the issue is mg5amcnlo/mg5amcnlo@0a1038d . This essentially replaces channel by iconfig in select_color. The commit title is "fix issue with the color selection " but I am not sure where the issue was observed.

Thanks!
Andrea

[valassi]

Hi @oliviermattelaer just to make it clearer: I have now "permanently" reverted your change in the upstream gpucpp.

This is to make sure we both work on the same code. Sorry I did not make it clearer before...
mg5amcnlo/mg5amcnlo@42cf68b

[oliviermattelaer]

Ok no problem, I will retest the process of @roiser with that commit to see if you re-introduced that error (or not).
Closing this for now.

[valassi]

Thanks Olivier, very good

[oliviermattelaer]

Hi @valassi , so ta+ta- is now working
but the following one:

generate p p > t t~
add process p p > t t~ j
add process p p > t t~ j j
output PROC_TEST --vector_size=8
launch
set nevents 50k

is now crashing with something related to color (I'm pretty sure it was working before).
So I guess that the best would be to have a skype talk about this, Since I do not understand what was the reason for you to revert my change.

And I confirm that after a

git revert 42cf68b -n

The above code is back to working as expected.

[valassi]

Hi @oliviermattelaer thanks.

The problem I have is that the lhe files produced by fortran and cudacpp are the same without your patch, while they are different with your patch, in gg to ttgg.

So it may be that

• your patch changes the colors in the fortran implementation, but not in the cudacpp: this is the most likely, can you check the effect of your patch in fortran gg to ttgg, and in case there is one, understand that?
• OR, your patch changes the colors in the cudacpp implementation, but not the fortran one: I think this is unlikely, but if it is the case it probably comes from the fortran/python too

I have not had time to debug this, sorry.

Having a chat is a good idea, but not today/tomorrow. Maybe next week Monday or Tuesday? Lets discuss offline.

Cheers Andrea

[oliviermattelaer]

So yes, I did change the colors only in the fortran implementation.
And did not touch the cudacpp one.

Will double check what is the impact for gg>ttgg but likely in that case just selecting different color (in a way selecting wrongly color).

Olivier

[valassi]

So yes, I did change the colors only in the fortran implementation. And did not touch the cudacpp one.

Will double check what is the impact for gg>ttgg but likely in that case just selecting different color (in a way selecting wrongly color).

Olivier

Thanks Olivier. I confirm that I have now permanently gone back to your latest select_color implementation in MR #709, which fixes #710, but reintroduces this #655.

Yes please let me know if you think that the ggttgg color choice is correct. If it is not correct, I leave it up to you to fix it in Fortran. If it is correct, I will take care of fixing it in cudacpp.

Note, this may be related to #713. I am now generating coloramps.h from coloramps.inc via sed, rather than via the python machinery directly. Maybe by using the python machinery directly, coloramps.h would look different from coloramps.h, but the lhe files would eventually be correct?...

[valassi]

This has been completed in MR #742.

@oliviermattelaer suggested to try and remove my patch that was recreating coloramps.h from coloramps.inc (#713), and use coloramps.h directly, using the results of his previous select_color changes. This turns out to fix the issue in color choices in ggttgg LHE files (fixing #655): a very simple change that fixes two issues at the same time.