Add fbridgesequence_nomultichannel #796

valassi · 2023-11-23T16:20:46Z

Hi @roiser @oliviermattelaer as discussed earlier on.

This is a MR that adds fortran call fbridgesequence_nomultichannel. It should be useful in Stefan's MR for trasnsforming channelid into an array.

As noted by @roiser, the issue is that fbridgesequence is presently called also with channelid=0 from the fortran (the integer is 0, not the pointer to the integer).

madgraph4gpu/epochX/cudacpp/gg_tt.mad/SubProcesses/P1_gg_ttx/auto_dsig1.f

Line 565 in b9f16e9

& HEL_RAND, COL_RAND, 0, OUT2,

        IF ( .NOT. MULTI_CHANNEL ) THEN
          CALL FBRIDGESEQUENCE(FBRIDGE_PBRIDGE, P_MULTI, ALL_G,
     &      HEL_RAND, COL_RAND, 0, OUT2,
     &      SELECTED_HEL2, SELECTED_COL2 ) ! 0: multi channel disabled

Technically it is possible from fortran to use a pointer (this is what we do for FBRIDGE_PBRIDGE via CppObjectInFortran struct), but it seems cumbersome here.

As noted by Stefan, better use a different function for the bridge sequence, this is what I have done here.

Note, initially I had misunderstood that the issue was eleiminating the #ifdef branch where multichannel is not supported. I tried this in the initial commits of this PR, but eventually this failed because it would break pure standalone code with no madevent, as there is no vcoloramps.h in that case and the code does not build. So I have also kept that anyway. Just to clarify, there are three use cases and they are all still supported

multichannel code, with channelid>0 (presently a scalar, eventuallay an array via a pointer)
multichannel code, with channelid=0 (presently a scalar, eventually a pointer=0 in cudacpp and a different function in fortran, i.e. this PR)
no-multichannel code (no coloramps.h), is pure standalone generation

Stefan I ask you as reviewer. Up to you if you want to include this now before your PR, or cherry-pick inside your PR, or do your PR first and then we merge this on top (I can fix teh conflicts in tht case).

Thanks Andrea

…ssume multichannel is always supported

…U_SUPPORTS_MULTICHANNEL

…ode as "wih multichannel" - the build fails ccache g++ -O3 -std=c++17 -I. -I../../src -Wall -Wshadow -Wextra -ffast-math -fopenmp -march=skylake-avx512 -mprefer-vector-width=256 -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -fPIC -c CPPProcess.cc -o CPPProcess.o CPPProcess.cc:30:10: fatal error: coloramps.h: No such file or directory 30 | #include "coloramps.h" | ^~~~~~~~~~~~~ compilation terminated.

Revert "[mch] regenerate gg_tt.sa, "without multichannel" but with the same code as "wih multichannel" - the build fails" This reverts commit f42c4bb. Revert "[mch] regenerate gg_tt.mad, all ok" This reverts commit 23f750f. Revert "[mch] backport to codegen from gg_tt.mad the removal of #ifdef MGONGPU_SUPPORTS_MULTICHANNEL" This reverts commit 71b6a74. Revert "[mch] in gg_tt.mad, remove #ifdef MGONGPU_SUPPORTS_MULTICHANNEL and assume multichannel is always supported" This reverts commit ce57dda.

@roiser

…ith @roiser

…nce_nomultichannel

./CODEGEN/generateAndCompare.sh gg_tt --mad --nopatch git diff --no-ext-diff -R gg_tt.mad/Source/makefile gg_tt.mad/Source/dsample.f gg_tt.mad/Source/genps.inc gg_tt.mad/SubProcesses/makefile > CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/MG5aMC_patches/PROD/patch.common git diff --no-ext-diff -R gg_tt.mad/bin/internal/banner.py gg_tt.mad/bin/internal/gen_ximprove.py gg_tt.mad/bin/internal/madevent_interface.py >> CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/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/PLUGIN/CUDACPP_SA_OUTPUT/MG5aMC_patches/PROD/patch.P1 git checkout gg_tt.mad NB: I have now removed make_opts from patch.common

… (will revert) ./tput/teeThroughputX.sh -ggtt -makeclean -makej ./tmad/teeMadX.sh -ggtt +10x

Revert "[mch] rerun tput and tmad tests for ggtt.mad as a cross check, all ok (will revert)" This reverts commit a395efb.

valassi · 2023-11-23T16:22:56Z

For an easier review, just look at this
d5c4c1b

The rest is code generation changes, and process regeneration

…patch.P1 and patch.common from scratch ./CODEGEN/generateAndCompare.sh gg_tt --mad --nopatch sed -i 's/DEFAULT_F2PY_COMPILER=f2py3.*/DEFAULT_F2PY_COMPILER=f2py3/' gg_tt.mad/Source/make_opts git diff --no-ext-diff -R gg_tt.mad/Source/make_opts gg_tt.mad/Source/makefile gg_tt.mad/Source/dsample.f gg_tt.mad/Source/genps.inc gg_tt.mad/SubProcesses/makefile > CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/MG5aMC_patches/PROD/patch.common git diff --no-ext-diff -R gg_tt.mad/bin/internal/banner.py gg_tt.mad/bin/internal/gen_ximprove.py gg_tt.mad/bin/internal/madevent_interface.py >> CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/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/PLUGIN/CUDACPP_SA_OUTPUT/MG5aMC_patches/PROD/patch.P1 git checkout gg_tt.mad NB1: In the instructions above, I changed the order of files in the patches (I moved make_opts to the beginning), to minimise differences in patch.common with respect to Stephan's. NB2: In another branch mch (PR madgraph5#796) I had decided to remove make_opts from patch.common: this is clearly no longer possible now Before this commit, i.e. using Stephan's patch.P1 and patch.common, this was happening: - code generation succeeds on itscrd90, fails on itscrd80 (patchMad.sh fails on the latter) - executing './CODEGEN/generateAndCompare.sh gg_tt --mad --nopatch' shows that the only difference between itscrd80 and itscrd90 is f2py (f2py3.9 on the former, f2py on the latter) After this commit, however: - code generation fails on itscrd90 (patchMad.sh fails, probably due to f2py issues)

…patch.P1 and patch.common from scratch (This is an old commit from 9 Dec but the description is still valid on 14 Dec) ./CODEGEN/generateAndCompare.sh gg_tt --mad --nopatch sed -i 's/DEFAULT_F2PY_COMPILER=f2py3.*/DEFAULT_F2PY_COMPILER=f2py3/' gg_tt.mad/Source/make_opts git diff --no-ext-diff -R gg_tt.mad/Source/make_opts gg_tt.mad/Source/makefile gg_tt.mad/Source/dsample.f gg_tt.mad/Source/genps.inc gg_tt.mad/SubProcesses/makefile > CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/MG5aMC_patches/PROD/patch.common git diff --no-ext-diff -R gg_tt.mad/bin/internal/banner.py gg_tt.mad/bin/internal/gen_ximprove.py gg_tt.mad/bin/internal/madevent_interface.py >> CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/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/PLUGIN/CUDACPP_SA_OUTPUT/MG5aMC_patches/PROD/patch.P1 git checkout gg_tt.mad NB1: In the instructions above, I changed the order of files in the patches (I moved make_opts to the beginning), to minimise differences in patch.common with respect to Stephan's. NB2: In another branch mch (PR madgraph5#796) I had decided to remove make_opts from patch.common: this is clearly no longer possible now Before this commit, i.e. using Stephan's patch.P1 and patch.common, this was happening: - code generation succeeds on itscrd90, fails on itscrd80 (patchMad.sh fails on the latter) - executing './CODEGEN/generateAndCompare.sh gg_tt --mad --nopatch' shows that the only difference between itscrd80 and itscrd90 is f2py (f2py3.9 on the former, f2py on the latter) After this commit, however: - code generation fails on itscrd90 (patchMad.sh fails, probably due to f2py issues)

valassi · 2023-12-16T08:20:06Z

I have just merged #706, I will modify this PR to merge in the new master

… PR madgraph5#706) ** regenerate all processes

…adgraph5#706) into mch Fix conflicts in CODEGEN logs by checking them out from upstream/master git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)

…pstream/master including PR madgraph5#706) - ok, changes are only in codegen logs

… common ancestor git merge-base --fork-point upstream/master 80ff716 git checkout 80ff716 $(git ls-tree --name-only HEAD */CODEGEN*txt)

…raph5#801 and gpucpp PR madgraph5#811, and possibly more) into mch

…ODEGEN logs

STARTED AT Sat Feb 3 06:00:52 PM CET 2024 ./tput/teeThroughputX.sh -mix -hrd -makej -eemumu -ggtt -ggttg -ggttgg -gqttq -ggttggg -makeclean ENDED(1) AT Sat Feb 3 06:31:47 PM CET 2024 [Status=0] ./tput/teeThroughputX.sh -flt -hrd -makej -eemumu -ggtt -ggttgg -inlonly -makeclean ENDED(2) AT Sat Feb 3 06:41:48 PM CET 2024 [Status=0] ./tput/teeThroughputX.sh -makej -eemumu -ggtt -ggttg -gqttq -ggttgg -ggttggg -flt -bridge -makeclean ENDED(3) AT Sat Feb 3 06:51:54 PM CET 2024 [Status=0] ./tput/teeThroughputX.sh -eemumu -ggtt -ggttgg -flt -rmbhst ENDED(4) AT Sat Feb 3 06:55:15 PM CET 2024 [Status=0] ./tput/teeThroughputX.sh -eemumu -ggtt -ggttgg -flt -curhst ENDED(5) AT Sat Feb 3 06:58:37 PM CET 2024 [Status=0]

…nd maybe more) ** rerun 18 tmad tests on itscrd90, all ok STARTED AT Sat Feb 3 07:02:02 PM CET 2024 ENDED AT Sat Feb 3 11:20:09 PM CET 2024 Status=0 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_eemumu_mad/log_eemumu_mad_d_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_eemumu_mad/log_eemumu_mad_f_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_eemumu_mad/log_eemumu_mad_m_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttggg_mad/log_ggttggg_mad_d_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttggg_mad/log_ggttggg_mad_f_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttggg_mad/log_ggttggg_mad_m_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttgg_mad/log_ggttgg_mad_d_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttgg_mad/log_ggttgg_mad_f_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttgg_mad/log_ggttgg_mad_m_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttg_mad/log_ggttg_mad_d_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttg_mad/log_ggttg_mad_f_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttg_mad/log_ggttg_mad_m_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggtt_mad/log_ggtt_mad_d_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggtt_mad/log_ggtt_mad_f_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggtt_mad/log_ggtt_mad_m_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_gqttq_mad/log_gqttq_mad_d_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_gqttq_mad/log_gqttq_mad_f_inl0_hrd0.txt 24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_gqttq_mad/log_gqttq_mad_m_inl0_hrd0.txt

valassi · 2024-02-05T08:11:50Z

Hi @oliviermattelaer this PR is also complete. It is one small ingredient of the work you are doing with @roiser to have many channels on the same grid. I would suggest putting this in independently of Stefan's work and doing it now. Otherwise every time there is a need to update to the latest master, retest etc.

Can you please @oliviermattelaer review and approve for merge?

As mentioned above the main change is just this one d5c4c1b which is really simple

Thanks Andrea

roiser · 2024-02-05T08:31:18Z

Actually with the latest changes that we need to make (no channel ids for CPU) I would propose to postpone this PR a bit if you don't mind. I haven't thought it through yet what the implications are.

valassi · 2024-02-05T09:25:58Z

Thanks @roiser. No I would very much prefer to merge this now. Having all these PRs in flight forces me to spend a large effort fixing conflicts and retesting. The sooner we get rid of open PRs so that we only have a more manageable number, the better.

Concerning this specific PR: it is so simple that it should not be a problem in the work you are doing now (and actually you asked for this initially so it cannot be bad!). It just adds a new function for the no-multichannel case and uses it where appropriate, in helicity filtering.

I would really merge this now. @oliviermattelaer what's your take?

Thanks Andrea

valassi · 2024-02-05T09:27:00Z

PS The fact that this now appears as not-mergeable is because I just merged PR #368. Probably easy conflicts to fix, but again I would rather not have to do this all the time. The sooner we merge this the better.

roiser · 2024-02-05T09:28:03Z

I'm just asking for postponing it by one or two days, the latest incompatibilities only came up on Friday, I can also incorporate it into the bigger channelID work if wanted.

valassi · 2024-02-05T10:11:28Z

I'm just asking for postponing it by one or two days, the latest incompatibilities only came up on Friday,

Ok for one or two days then...

I can also incorporate it into the bigger channelID work if wanted.

I would still find it cleaner to have separate PRs for separate issues - in general. If you want I can reduce this to essentially one cherry-pick in the CODEGEN part, and hide away all changes in generated code and test logs, so that it's easier to merge. It becomes equivalent to a cherry-pick on your side.

roiser · 2024-02-06T10:30:30Z

epochX/cudacpp/CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/madgraph/iolibs/template_files/gpu/fbridge.inc

@@ -56,6 +56,31 @@ C
         END SUBROUTINE FBRIDGESEQUENCE
      END INTERFACE

+C


I cannot leave a comment in code that was not changed, but I would propose in the line 52 above to change to

INTEGER*4 CHANID(*)

I have done this change in the new_interface_wrap branch, see

madgraph4gpu/epochX/cudacpp/gg_tt.mad/SubProcesses/fbridge.inc

Line 52 in b317cbf

INTEGER*4 CHANID(*)

and this seems to work correctly.

Hi @roiser thanks for having a look.

I think these are two different issues:

in my PR here, channelid is still a scalar, and so this must be CHANID and not CHANID(*)

in your upcoming PR, you will indeed need to change CHANID to CHANID(*)

Specifically, if I simply change myself CHANID to CHANID(*). then this fails the build

ccache /cvmfs/sft.cern.ch/lcg/releases/gcc/12.1.0-57c96/x86_64-centos9/bin/gfortran -w -fPIC -O3 -ffast-math -fbounds-check -ffixed-line-length-132 -w -cpp -c -DMG5AMC_MEEXPORTER_CUDACPP auto_dsig1.f -I../../Source/ -fopenmp -o auto_dsig1_cudacpp.o auto_dsig1.f:573:32: 573 | & HEL_RAND, COL_RAND, CHANNEL, OUT2, | 1 Error: Rank mismatch in argument 'chanid' at (1) (rank-1 and scalar)

I would suggest to keep this in two different PRs

here I just add the new method and keep CHANID

in your PR you will then change CHANID to CHANID(*)

Does this sound ok? Please let me know if you think this can be merged @roiser thanks

But this PR emerged out of the work for channel id arrays. If I do not remember correctly and it was done for another purpose please merge this here and I would adapt then with the later channel id PR if needed.

No it was indeed done for that purpose. But it does not harm to include it anyway (it does simplify one function call without multichannel support). I would include it anyway now so that there is no need for further conflict fixes etc. It makes completely sense by itself and was fully tested by itself.

roiser · 2024-02-06T10:35:55Z

I'm just asking for postponing it by one or two days, the latest incompatibilities only came up on Friday,

Ok for one or two days then...

I looked through the code and found one possibly minor issue, please have a look at the comment above. Otherwise I imagine this should work. @oliviermattelaer you would need to pass me an INTEGER*4 (*) in cases the channel id is used. Following our latest discussion IIUC for CPU this would be only of length 1, is this possible for you to distinguish?

…se merging of upstream/master here (and later to ease the merge of master into Stefan's work) git checkout upstream/master tput/logs* tmad/logs* git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)

…5#368) into mch

roiser · 2024-02-06T14:12:15Z

please go ahead then, thanks Stefan

…ion of FP vector by a boolean mask (for channel array madgraph5#765)

…nstrate multiplication of FP vector by a boolean mask (for channel array madgraph5#765)

… testmisc.cc Checked that code generation of gg_tt.mad is now stable

for f in $(git ls-tree --name-only HEAD */SubProcesses/testmisc.cc); do \cp gg_tt.mad/SubProcesses/testmisc.cc $f; done

… ** improve a comment in CODEGEN and generated code for testmisc.cc (boolean vector times float vector, not integer vector times float vector)

valassi · 2024-02-08T15:36:05Z

please go ahead then, thanks Stefan

Thanks I will merge then

…am/master' (including fbridgesequence_nomultichannel PR madgraph5#796) into rocrand Checked that ggtt.mad can be regenerated correctly an dthat its tput/tmad tests succeed

valassi added 12 commits November 23, 2023 15:09

[mch] in gg_tt.mad, remove #ifdef MGONGPU_SUPPORTS_MULTICHANNEL and a…

ce57dda

…ssume multichannel is always supported

[mch] backport to codegen from gg_tt.mad the removal of #ifdef MGONGP…

71b6a74

…U_SUPPORTS_MULTICHANNEL

[mch] regenerate gg_tt.mad, all ok

23f750f

[mch] in gg_tt.mad, add fbridgesequence_nomultichannel as discussed w…

d5c4c1b

…ith @roiser

[mch] backport from gg_tt.mad to codegen the addition of fbridgeseque…

59b4a34

…nce_nomultichannel

[mch] regenerate gg_tt.mad with latest codegen, all ok no changes

aabf6c6

[mch] rerun tput and tmad tests for ggtt.mad as a cross check, all ok…

a395efb

… (will revert) ./tput/teeThroughputX.sh -ggtt -makeclean -makej ./tmad/teeMadX.sh -ggtt +10x

[mch] revert to upstream/master tput/tmad logs

a5323b2

Revert "[mch] rerun tput and tmad tests for ggtt.mad as a cross check, all ok (will revert)" This reverts commit a395efb.

[mch] regenerate ggtt.sa and test that builds are ok

26d6f15

valassi requested a review from roiser November 23, 2023 16:20

valassi assigned roiser and valassi Nov 23, 2023

This was referenced Nov 24, 2023

fix FPEs and debug nobm_pp_ttW for ATLAS #706

Merged

Out-of-bounds memory access in random color choice #611

Closed

Remove (or simplify) ifdefs for MULTICHANNEL #568

Closed

valassi added 2 commits December 16, 2023 09:24

[mch] ** COMPLETE MCH (but need to merge in upstream/master including…

05f9796

… PR madgraph5#706) ** regenerate all processes

Merge remote-tracking branch 'upstream/master' (including merged PR m…

ff7e3c2

…adgraph5#706) into mch Fix conflicts in CODEGEN logs by checking them out from upstream/master git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)

valassi force-pushed the mch branch from eaa0416 to 5226ced Compare December 16, 2023 08:31

[mch] ** COMPLETE MCH ** regenerate all processes (after merging in u…

d2ebfb9

…pstream/master including PR madgraph5#706) - ok, changes are only in codegen logs

valassi force-pushed the mch branch from 5226ced to d2ebfb9 Compare December 16, 2023 08:41

valassi added 3 commits February 3, 2024 17:44

[mch] prepare to merge upstream/master - go back to CODEGEN logs from…

89fce3e

… common ancestor git merge-base --fork-point upstream/master 80ff716 git checkout 80ff716 $(git ls-tree --name-only HEAD */CODEGEN*txt)

Merge remote-tracking branch 'upstream/master' (including HIP PR madg…

62744a6

…raph5#801 and gpucpp PR madgraph5#811, and possibly more) into mch

[mch] regenerate all processes after merging - no change except for C…

5676713

…ODEGEN logs

valassi added 2 commits February 4, 2024 20:47

valassi requested a review from oliviermattelaer February 5, 2024 08:12

roiser reviewed Feb 6, 2024

View reviewed changes

valassi added 2 commits February 6, 2024 12:22

Merge remote-tracking branch 'upstream/master' (including PR madgraph…

1d59c1c

…5#368) into mch

valassi added 5 commits February 7, 2024 09:00

[mch] in gg_tt.mad testmisc.cc, add a test to demonstrate multiplicat…

9fab474

…ion of FP vector by a boolean mask (for channel array madgraph5#765)

[mch] in CODEGEN testmisc.cc (backport gg_tt.mad), add a test to demo…

0d2a508

…nstrate multiplication of FP vector by a boolean mask (for channel array madgraph5#765)

[mch] in CODEGEN and gg_tt.mad, fix clang formatting of test added to…

cc882e4

… testmisc.cc Checked that code generation of gg_tt.mad is now stable

[mch] manually copy the updated testmisc.cc to all generated processes

ee3cd7b

for f in $(git ls-tree --name-only HEAD */SubProcesses/testmisc.cc); do \cp gg_tt.mad/SubProcesses/testmisc.cc $f; done

[mch] **COMPLETE MCH (after merging madgraph5#368 plus minor changes)…

bd581e7

… ** improve a comment in CODEGEN and generated code for testmisc.cc (boolean vector times float vector, not integer vector times float vector)

valassi force-pushed the mch branch from 064a900 to bd581e7 Compare February 7, 2024 08:28

valassi merged commit 57c1ba6 into madgraph5:master Feb 8, 2024
57 checks passed

valassi mentioned this pull request Feb 9, 2024

add support for ROCRAND (via HIPRAND) #809

Merged

valassi mentioned this pull request Jul 8, 2024

master_june24: nomultichannel should be an array nullptr, not an array full of 0s #892

Closed

valassi mentioned this pull request Jul 17, 2024

master_june24: fbridgesequence_nomultichannel is not used #914

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add fbridgesequence_nomultichannel #796

Add fbridgesequence_nomultichannel #796

valassi commented Nov 23, 2023

valassi commented Nov 23, 2023

valassi commented Dec 16, 2023

valassi commented Feb 5, 2024

roiser commented Feb 5, 2024

valassi commented Feb 5, 2024

valassi commented Feb 5, 2024

roiser commented Feb 5, 2024

valassi commented Feb 5, 2024

roiser Feb 6, 2024

valassi Feb 6, 2024 •

edited

Loading

roiser Feb 6, 2024

valassi Feb 6, 2024

roiser commented Feb 6, 2024 •

edited

Loading

roiser commented Feb 6, 2024

valassi commented Feb 8, 2024

Add fbridgesequence_nomultichannel #796

Add fbridgesequence_nomultichannel #796

Conversation

valassi commented Nov 23, 2023

valassi commented Nov 23, 2023

valassi commented Dec 16, 2023

valassi commented Feb 5, 2024

roiser commented Feb 5, 2024

valassi commented Feb 5, 2024

valassi commented Feb 5, 2024

roiser commented Feb 5, 2024

valassi commented Feb 5, 2024

roiser Feb 6, 2024

Choose a reason for hiding this comment

valassi Feb 6, 2024 • edited Loading

Choose a reason for hiding this comment

roiser Feb 6, 2024

Choose a reason for hiding this comment

valassi Feb 6, 2024

Choose a reason for hiding this comment

roiser commented Feb 6, 2024 • edited Loading

roiser commented Feb 6, 2024

valassi commented Feb 8, 2024

valassi Feb 6, 2024 •

edited

Loading

roiser commented Feb 6, 2024 •

edited

Loading