-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event by event random choice of one color #573
Conversation
… variable in sigmaKin for up to 2*neppV events
…olor choice madgraph5#402, also try to simplify nParity ifdefs
…or (inline in sigmaKin, remove select_color) NB does not build because it is missing the isLeadingColor function...
…lection in BothDebug mode
…) for leading color selection madgraph5#402
…random choice of color madgraph5#402 in CPPProcess.cc - random color always 1?
…random color now 1 or 2 but C++ different from Fortran
…C indices) - still Fortran differs from C++ (but CUDA is ok!)
Revert "[lhe] add debug printouts in fortran and c++ for the random color choice" This reverts commit aa4d429b79a43b137ae49d385dc4f22c4c49d07d.
…nitialise jamp2_sv for every SIMD page) - OK NOW! Fortran same as C++
…r/helicity comparison, all ok!
…ocessExporterCPP.get_icolamp_lines instead! Revert "[lhe] WIP in CODEGEN WIP to generate coloramps.h" This reverts commit 62f9526cd1110f99a07eb28e3a42322d48ab5782.
…use is_LC as in OneProcessExporterCPP)
…NOT needed for vectorised color selection Revert "[lhe] in gg_tt.mad add an int_v typedef for vectorised color selection madgraph5#402" This reverts commit 71565e4.
…ntvFromAlignedArray Revert "[lhe] in gg_tt.mad add intvFromAlignedArray" This reverts commit f721c49.
…sion from codegen
…sons of Fortran/C++ colors in auto_dsig1.f) ./CODEGEN/generateAndCompare.sh gg_tt --mad --nopatch git diff --no-ext-diff -R gg_tt.mad/Source/dsample.f gg_tt.mad/Source/genps.inc gg_tt.mad/Source/vector.inc gg_tt.mad/SubProcesses/makefile > CODEGEN/MG5aMC_patches/PROD/patch.common git diff --no-ext-diff -R gg_tt.mad/SubProcesses/P1_gg_ttx/auto_dsig1.f gg_tt.mad/SubProcesses/P1_gg_ttx/driver.f gg_tt.mad/SubProcesses/P1_gg_ttx/matrix1.f > CODEGEN/MG5aMC_patches/PROD/patch.P1 git checkout gg_tt.mad
…amps.h unless in multichannel mode
…and other cosmetics)
Ok I fixed the bug, regenerated all processes, now rerunning tests. I guess that the bug was not showing up in ggtt chanel 1 because there only two channels exist and both are selected by icolamp. The bug was there when icolamp was not selecting all colors in a given channel |
…tggg ok, but ggttgg fails? STARTED AT Sat Dec 17 10:27:33 CET 2022 ENDED AT Sat Dec 17 16:10:09 CET 2022
This is becoming very tiring. Now ggttgg fails (while all others including ggttggg succeed)
|
Ok so the root cause here is that for the channel 1 that I am using, coloramps.inc and coloramps.h are not the same thing...
I suspected this by looking at the targetamps... for the same event, it is a different set of colors in fortran and cpp that are considered leading
|
Hi @oliviermattelaer is this caused by mg5amcnlo/mg5amcnlo#5? Now that I read it, I would imagine so... For completeness, the main goal was to be able to have the same index for the identification of the amp2 index as for the one related to the definition of the allowed color flow for the event." I had completely forgotten that we discussed this in June and that I should include it... |
Hi @oliviermattelaer @roiser I am moving this back to draft. I need to first upgrade the upstream to https://github.com/mg5amcnlo/mg5amcnlo/pull/5/files The problem is that that pull request does not work against vecMLM which is what we use now. So we need to fix the conflicts first. I can give it a try, but I am not sure I would do it right |
Well in the end I am also trying a simple hack. By using brute force sed/awk I transformed coloramps.inc into coloramps.h in such a way that they have the same definition of icolamp. Assuming that the one in Fortran is correct (is it?!) then also the one in cudacpp is correct. I am running the tests now. If they succeed, I will merge and consider this part closed. Of course the code generation must be done properly and the lovectdiag must be merged, but at least we might say we have randol color choice. |
… will not be backported) git format-patch c686761 -1 patch -R -p6 -i 0001-lhe-in-ggttg.mad-revert-debug-printouts.patch
…e first 'vecsize' patch
…mments in fortran (no need to regenerate sa)
…nt as coloramps.inc
…nc with $ continuation signs
…from coloramps.inc No need to regenerate SA processes, they have no coloramps.h
…put alltees - finally all ok This completes the random color choice madgraph5#402 This took around 8 hours from 1h to 9h STARTED AT Sun Dec 18 07:32:03 CET 2022 ./tput/teeThroughputX.sh -flt -hrd -makej -eemumu -ggtt -ggttg -ggttgg -ggttggg -makeclean ENDED(1) AT Sun Dec 18 08:39:14 CET 2022 [Status=0] ./tput/teeThroughputX.sh -flt -hrd -makej -eemumu -ggtt -ggttgg -inlonly -makeclean ENDED(2) AT Sun Dec 18 09:00:20 CET 2022 [Status=0] ./tput/teeThroughputX.sh -makej -eemumu -ggtt -ggttg -ggttgg -ggttggg -flt -bridge -makeclean ENDED(3) AT Sun Dec 18 09:09:51 CET 2022 [Status=0] ./tput/teeThroughputX.sh -eemumu -ggtt -ggttgg -flt -rmbhst ENDED(4) AT Sun Dec 18 09:13:28 CET 2022 [Status=0] ./tput/teeThroughputX.sh -eemumu -ggtt -ggttgg -flt -curhst ENDED(5) AT Sun Dec 18 09:17:01 CET 2022 [Status=0]
I consider this complete - within madgraph4gpu, that is, within the context of my custom patches. Eventually we need to fix coloramps.h out of the box in upstream mg5amcnlo but this is another story. The important point here is: when coloramps.h and coloramps.inc hav ethe same contents, then Fortran and cudacpp produce the same LHE files including random color choice. I will self merge as soon as the CI tests succed. This will close #402. |
BUT THIS IS SLOWER! (Probably because I am using ieppV loops now...) FPTYPE=m make -j -f cudacpp.mk ./check.exe -p 2048 256 1 | egrep '(EvtsPerSec\[MECalcOnly|^MeanMa)' EvtsPerSec[MECalcOnly] (3a) = ( 6.139981e+05 ) sec^-1 MeanMatrixElemValue = ( 2.085623e+00 +- 4.835084e-03 ) GeV^0 For comparison, in this commit with double: FPTYPE=d make -j -f cudacpp.mk ./check.exe -p 2048 256 1 | egrep '(EvtsPerSec\[MECalcOnly|^MeanMa)' EvtsPerSec[MECalcOnly] (3a) = ( 6.268384e+05 ) sec^-1 MeanMatrixElemValue = ( 2.085623e+00 +- 4.835084e-03 ) GeV^0 For comparison, in hack2 with double: FPTYPE=d make -j -f cudacpp.mk ./check.exe -p 2048 256 1 | egrep '(EvtsPerSec\[MECalcOnly|^MeanMa)' EvtsPerSec[MECalcOnly] (3a) = ( 6.265465e+05 ) sec^-1 MeanMatrixElemValue = ( 2.085623e+00 +- 4.835084e-03 ) GeV^0
… CUDA, just the color matrix for C++) madgraph5#573 FPTYPE=m make -j -f cudacpp.mk ./gcheck.exe -p 64 256 1 | egrep '(EvtsPerSec\[MECalcOnly|^MeanMa)' EvtsPerSec[MECalcOnly] (3a) = ( 3.992718e+05 ) sec^-1 [VARIES 3.78-3.99] MeanMatrixElemValue = ( 4.063123e+00 +- 2.368970e+00 ) GeV^-4 ./check.exe -p 64 256 1 | egrep '(EvtsPerSec\[MECalcOnly|^MeanMa)' EvtsPerSec[MECalcOnly] (3a) = ( 8.003095e+03 ) sec^-1 [VARIES 8.00-8.00] MeanMatrixElemValue = ( 4.063123e+00 +- 2.368970e+00 ) GeV^-4 ** NB: THE MEAN MATRIX ELEMENT VALUE HAS NOT MOVED AT ALL, SAME PRECISION! **
Hi @oliviermattelaer @roiser I made progress for the random choice of color #402
This is still in WIP because I need amongst other things