Add an example of a calculation with nprocesses>1 #272

valassi · 2021-10-21T09:58:44Z

Just a reminder. In the epochX work #244, I kept several of the comments I had all over the code "FIXME this assumes nprocesses=1". I am not sure what the code should look like or how it should behave with nprocesses>1.

Eventually we need to add a test of one simple such example. This may even be a very simple process, as long as it has nprocesses>1.

@oliviermattelaer maybe this is for you to suggest one ;-)

Low priority anyway (Fortran integration is more important)

valassi · 2021-10-21T16:55:10Z

Maybe pp to tt? David suggested that it may be useful to try this anyway for other reasons.

valassi · 2022-01-20T18:59:38Z

Adding pptt is definitely needed - Olivier's bug #337 probably comes from this

valassi · 2022-03-08T15:31:32Z

In PR #396 for #343, I am removing mirror processes in uutt as done by @oliviermattelaer in branch 311. This means that now pptt subprocesses all have nprocesses==1.

Actually I have even added a static assert for nprocesses==1. To go beyond this, we should add an example with nprocesses>1.

Os, actually: was nprocesses>1 ONLY necessary for "mirror processes", and can this now be completely removed if these have been removed?... (question for @oliviermattelaer )

valassi · 2022-06-15T08:46:55Z

Is this also related to the difference between MAXFLOW and NCOLOR in the fortran? oliviermattelaer/mg5amc_test#21

oliviermattelaer · 2023-03-23T08:01:46Z

So in the latest gpucpp branch.
All P directories would have exactly one matrix-element function.
This matrix-element can still be related to multiple initial/final state but all of them will have the exact same matrix-element.

(Compare to my original email, this is now done in a "decent" way meaning that identical matrix-element are correctly handle)

valassi · 2023-03-31T09:21:36Z

Thanks Olivier! I updated to your latest upstream code in PR #619.

This is related to the discussion we had at the meeting earlier this wek https://indico.cern.ch/event/1263518/
You showed that for instance this process changes as follows

I could close this as fixed by PR #619. But I will keep it open for now, maybe I will clean up the code, remove a lot of nprocesses and/or add a few cleaner comments mentioning this #272 and PR #619

…l ok with no change This completes the first "susy" patch: now susy_gg_tt can be generated correctly (but it does not build). In practice, the main (only?) issue it addresses is madgraph5#622 Further patches (susy2 and possibly more) will attempt to fix these builds. NB: At this stage, CODEGEN is still using the upstream mg5amcnlo without "split_nonidentical_grouping" (PR madgraph5#619 and madgraph5#272)

NB this has two P1 subdirectories gu_ttxu/gux_ttxux! (but nprocesses=1 in each see madgraph5#272) The code builds and runs successfully in each of the two subdirectories

NB this has a single P1 subdirectory gq_ttxq! (but nprocesses=1 in each see madgraph5#272) The Fortran code has DSIG1 and also DSIG2. Clearly the DSIG2 code is not correctly interfaced to our cudacpp The code fails to build: ... ccache g++ -O3 -std=c++17 -I. -I../../src -I../../../../../tools -DUSE_NVTX -Wall -Wshadow -Wextra -ffast-math -fopenmp -march=skylake-avx512 -mprefer-vector-width=256 -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -I/usr/local/cuda-12.0/include/ -fPIC -c CPPProcess.cc -o CPPProcess.o In file included from CPPProcess.cc:25: coloramps.h:18:3: error: too many initializers for ‘const bool [5][4]’ 18 | }; | ^ ... ccache /usr/local/cuda-12.0/bin/nvcc -O3 -lineinfo -I. -I../../src -I../../../../../tools -I/usr/local/cuda-12.0/include/ -DUSE_NVTX -gencode arch=compute_70,code=compute_70 -gencode arch=compute_70,code=sm_70 -use_fast_math -std=c++17 -ccbin /usr/lib64/ccache/g++ -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -Xcompiler -fPIC -c gCPPProcess.cu -o gCPPProcess.o coloramps.h(13): error: too many initializer values NB this is still using the old upstream mg5amcnlo before Olivier's split_nonidentical_grouping (see madgraph5#619) I have previewed that after merging that, there will be two separate P1 subdirectories also in .mad (as in .sa)

This is cmd="define q = u c d s u~ c~ d~ s~; generate g q > t t~ l- l+ q" This currently generates successfully, but has some formatting issues in codegen Note: this has several DSIG1, DSIG2, DSIG3, DSIG4 in the Fortran for .mad, but still nprocesses=1 in the CUDACPP I had initially tested this for madgraph5#272, but in the end gq_ttq is enough (I will keep it in codegen anyway) Note: this has four separate directories in the .sa. The build fails, eg in the first one [avalassi@itscrd90 gcc11/usr] /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/gq_ttllq.sa/SubProcesses/P1_Sigma_sm_gu_ttxemepu> make -j ccache g++ -O3 -std=c++17 -I. -I../../src -I../../../../../tools -DUSE_NVTX -Wall -Wshadow -Wextra -ffast-math -fopenmp -march=skylake-avx512 -mprefer-vector-width=256 -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -I/usr/local/cuda-12.0/include/ -fPIC -c CPPProcess.cc -o CPPProcess.o CPPProcess.cc: In function ‘void mg5amcCpu::calculate_wavefunctions(int, const fptype*, const fptype*, mgOnGpu::fptype*, fptype_sv*, int)’: CPPProcess.cc:286:85: error: wrong type argument to unary minus 286 | FFV2_5_0<W_ACCESS, A_ACCESS, CI_ACCESS>( w_fp[10], w_fp[6], w_fp[11], -COUPs[3], COUPs[5], &amp_fp[0] ); | ~~~~~~~^ (I initially thought this only hapened in SUSY processes, but actually it also happens in this SM process...)

valassi · 2023-04-03T20:24:59Z

In the end I have done a lot more analysis about this issue. I did not want to simply merge MR #619 and close this one. I wanted to make sure that before the MR we had a problem with nprocesses>1, and after the MR we did not.

This took several iterations and extra issues opened on the way

I wanted to reproduce Olivier's screesnhot above to see what has changed.
I understood the above probably came from work done with Nathan on https://github.com/nscottnichols/madgraph4gpu/blob/f9689784390e2975a055711b3a8d79f7b7688860/epochX/sycl/CODEGEN/generateAndCompare2.sh#L58 on a SUSY example, so I tried several SUSY examples, initially gq_ttllq. On the way I opened Fixes for SUSY code generation of gg_tt #624 fix susy gg_tt builds and add it to the repo #625 SUSY HRDCOD=1 builds fail because sin/cos/atan are not constexpr (only CUDA fails, while C++ succeeds) #627 wrong type argument to unary minus (FFV functions should not use "-COUPs" as argument) #628
Then I actually realised I could probably just test a SM process like gq_ttq (but I also did gq_ttllq for SM), Add SM gq to ttq (and gq to ttllq) - example of a process with DSIG1 and DSIG2 #626 (which also gave some of the issues above)
Then I also tried in parallel to produce the plot with "launch", and this gave me My "vecsize" patches have broken mg5amcnlo "launch" for the default Fortran madevent #629

Anyway, my understanding now is the following (I will discuss with Olivier)

the issue we discuss here comes from things like gq_ttq where the initial and final q can be both u or a ubar
within the fortran, the "nprocesses>1" means that there are actually DSIG1 and DSIG2 in a single P1 directory... correspondingly, one could have expected nprocesses=2 in cudacpp inside a single P1 directory
however, one workaorund is to split this into two separate P1 directories: this is Olivier's split_nonidentical_grouping" and Upgrade to Olivier's latest gpucpp branch upstream ("split_nonidentical_grouping") #619: I have checked that in the end this gives indeed two P1 subdirectories, with only one DSIG1 in each
note well, Olivier's patch uses two P1 directpies ONLY if cudacpp is an exporter: so not in madevent with Fortran MEs... note also, the standalone cudacpp was ALREADY doing two separate directories... so the issue was really only madevent+cudacpp
note that, by going to several P1 directories, we will hit even more the issues in Add pp_tttt as an example of a process with many P1 subdirectories which need different nwf values #534

So in a way this #272 (nprocesses>1) and the #534 (more than one P1) are related, because the sam eissues can be moved from the former to the latter

In practice now

I think I will add gqttq with a single P1 and with DSIG1/DIG2 in Add SM gq to ttq (and gq to ttllq) - example of a process with DSIG1 and DSIG2 #626
on the way, in the above I will CLEAN UP MESSAGES ABOUT NPROCESSES in the code
then and only then I will merge Upgrade to Olivier's latest gpucpp branch upstream ("split_nonidentical_grouping") #619, showing that there are now two P1 with a single DSIG1
then I will fix gq_ttq in this new configuration
Along the way, we need (in Add back make -j avxall to tput/throughputX.sh script #536) also to add the infrastructure for tput/tmad tests (and builds!!) from more than one P1

oliviermattelaer · 2023-04-04T08:04:50Z

also it seems that some matrix element are missing (the symmetric ones) in the susy case, this need to be fix.

NB this has two P1 subdirectories gu_ttxu/gux_ttxux! (but nprocesses=1 in each see madgraph5#272) The code builds and runs successfully in each of the two subdirectories

NB this has a single P1 subdirectory gq_ttxq! (but nprocesses=1 in each see madgraph5#272) The Fortran code has DSIG1 and also DSIG2. Clearly the DSIG2 code is not correctly interfaced to our cudacpp The code fails to build: ... ccache g++ -O3 -std=c++17 -I. -I../../src -I../../../../../tools -DUSE_NVTX -Wall -Wshadow -Wextra -ffast-math -fopenmp -march=skylake-avx512 -mprefer-vector-width=256 -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -I/usr/local/cuda-12.0/include/ -fPIC -c CPPProcess.cc -o CPPProcess.o In file included from CPPProcess.cc:25: coloramps.h:18:3: error: too many initializers for ‘const bool [5][4]’ 18 | }; | ^ ... ccache /usr/local/cuda-12.0/bin/nvcc -O3 -lineinfo -I. -I../../src -I../../../../../tools -I/usr/local/cuda-12.0/include/ -DUSE_NVTX -gencode arch=compute_70,code=compute_70 -gencode arch=compute_70,code=sm_70 -use_fast_math -std=c++17 -ccbin /usr/lib64/ccache/g++ -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -Xcompiler -fPIC -c gCPPProcess.cu -o gCPPProcess.o coloramps.h(13): error: too many initializer values NB this is still using the old upstream mg5amcnlo before Olivier's split_nonidentical_grouping (see madgraph5#619) I have previewed that after merging that, there will be two separate P1 subdirectories also in .mad (as in .sa)

This is cmd="define q = u c d s u~ c~ d~ s~; generate g q > t t~ l- l+ q" This currently generates successfully, but has some formatting issues in codegen Note: this has several DSIG1, DSIG2, DSIG3, DSIG4 in the Fortran for .mad, but still nprocesses=1 in the CUDACPP I had initially tested this for madgraph5#272, but in the end gq_ttq is enough (I will keep it in codegen anyway) Note: this has four separate directories in the .sa. The build fails, eg in the first one [avalassi@itscrd90 gcc11/usr] /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/gq_ttllq.sa/SubProcesses/P1_Sigma_sm_gu_ttxemepu> make -j ccache g++ -O3 -std=c++17 -I. -I../../src -I../../../../../tools -DUSE_NVTX -Wall -Wshadow -Wextra -ffast-math -fopenmp -march=skylake-avx512 -mprefer-vector-width=256 -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -I/usr/local/cuda-12.0/include/ -fPIC -c CPPProcess.cc -o CPPProcess.o CPPProcess.cc: In function ‘void mg5amcCpu::calculate_wavefunctions(int, const fptype*, const fptype*, mgOnGpu::fptype*, fptype_sv*, int)’: CPPProcess.cc:286:85: error: wrong type argument to unary minus 286 | FFV2_5_0<W_ACCESS, A_ACCESS, CI_ACCESS>( w_fp[10], w_fp[6], w_fp[11], -COUPs[3], COUPs[5], &amp_fp[0] ); | ~~~~~~~^ (I initially thought this only hapened in SUSY processes, but actually it also happens in this SM process...)

…neProcessExporter (0 in standalone, 1,2... in madevent+cudacpp) This will later be forced to be always equal to 0 or 1 (there must be a single DSIG1!) This is essentially what the 'nprocesses=1' assumption of madgraph5#272 is about. But it seems that nprocesses already is always 1 in generated code (will keep that too).

…proc and codegen_procid (for sanity checks only madgraph5#272 and madgraph5#619)

…oc and codegen_procid (for sanity checks only madgraph5#272 and madgraph5#619)

…me process.nprocesses == 1" (madgraph5#272 and madgraph5#343)

… comments madgraph5#272 and madgraph5#343

…1_gux_ttxux to P1_gu_ttxu The gqttq tests fail anyway and will need to be fixed (madgraph5#630). However, this completes the addition of gq_ttq as a new process to the repo. In particular it includes proof that Olivier's "split_nonidentical_grouping" madgraph5#619 fixes the gqttq builds. It also includes a lot of cleanup for "nprocesses" (madgraph5#272 and madgraph5#343) Revert "[gqttq] retry the tmad gqttq test with the P1_gu_ttxu directory - the test continues to fail (madgraph5#630)" This reverts commit 2dea1f7. Revert "[gqttq] temporarely use P1_gu_ttxu instead of P1_gux_ttxux for gqttq tmad tests" This reverts commit ea23a9a.

valassi · 2023-04-05T10:32:28Z

also it seems that some matrix element are missing (the symmetric ones) in the susy case, this need to be fix.

thanks Olivier... can you elaborate please? which process? expect build/runtime failures or just wrong results? I am about to close this issue, we can open a new one (unless this is covered by the other issues already open for SUSY)

…dgraph5#272 and madgraph5#343 (see also PRs madgraph5#619, madgraph5#626, madgraph5#360 and madgraph5#396)

valassi · 2023-04-07T07:48:54Z

I am finally closing this. There have been a lot of changes (and I am not 100% sure I understand all the implications), but essentially cudacpp is now configured so that

there are no "mirror processes" (which for instance were giving nprocesses=2 in uux_ttx in branch 270, see Fix "nprocesses>1" code generation (example: uutt within pptt gives "const int denominators = 36,36;") #343 and PRs Port epochX CODEGEN from 270gpu to the 311lovec branch (and pick up the new features there!) #360 and Disable mirror processes (nprocesses=2 in pptt) + Add process name to library names #396)... which probably is what fixed this Add an example of a calculation with nprocesses>1 #272
in addition (I think this is a different issue, even if also related to quark-antiquark exchange?) there are no processes with both a DSIG1 and DSIG2 (i.e. also both matrix1.f and matrix2.f), because of Olivier's "split_nonidentical_grouping" changes picked up in PR Upgrade to Olivier's latest gpucpp branch upstream ("split_nonidentical_grouping") #619 (and tested in gq_ttq in PR Add SM gq to ttq (and gq to ttllq) - example of a process with DSIG1 and DSIG2 #626, which also cleans up all comments about nprocesses==1)... now those end up as two separate P1 directories instead

I have added some improved comments about the issues above in PR #635, which I have just merged.

One last word: having removed mirror processes and the possibility to have DSIG2, now cudacpp relies on having several P1 subdirectories. In some cases (actually not the pp_tt or gq_ttq processes above), there are problems because some files should be different in the various P1 and they are not: see for instance pp to tttt in WIP PR #534, where the value of nwf should be different. [NB I have tested that this issue happens in pp_tttt but not in pp_tt]

For the summary of the summary, about the "example processes"

pp to tt (and specifically uux to ttx within that) was an example of mirror process, giving nprocesses>1 in branch 270 before Disable mirror processes (nprocesses=2 in pptt) + Add process name to library names #396, fixed long ago
gq to ttq (or more precisily gu to ttu AND gux to ttux) was an example of a process with both DSIG1 and DSIG2 in the same P1 directory, before PRs Upgrade to Olivier's latest gpucpp branch upstream ("split_nonidentical_grouping") #619 and Add SM gq to ttq (and gq to ttllq) - example of a process with DSIG1 and DSIG2 #626, now fixed and resulting in several P1 subdirectories
pp to tttt (see WIP PR Add pp_tttt as an example of a process with many P1 subdirectories which need different nwf values #534) is an example of a process with many P1 subdirectoies, but where nwf must be different in the various directories (this is NOT The case of pp_tt or gq_ttq above, where all P1 builds are ok)
as a consequence, gq_ttq has been added to the repo and pp_tttt will also be added to the repo

FINALLY closing this.

cc: @roiser @oliviermattelaer @zeniheisser

…neProcessExporter (0 in standalone, 1,2... in madevent+cudacpp) This will later be forced to be always equal to 0 or 1 (there must be a single DSIG1!) This is essentially what the 'nprocesses=1' assumption of madgraph5/madgraph4gpu#272 is about. But it seems that nprocesses already is always 1 in generated code (will keep that too).

…proc and codegen_procid (for sanity checks only madgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#619)

…oc and codegen_procid (for sanity checks only madgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#619)

…me process.nprocesses == 1" (madgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#343)

…dgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#343 (see also PRs madgraph5/madgraph4gpu#619, madgraph5/madgraph4gpu#626, madgraph5/madgraph4gpu#360 and madgraph5/madgraph4gpu#396)

…matting, and especially the build will fail. Codebase includes merging commit a6731bd (Olivier Wed Aug 23 13:23:12 2023 +0200) This uses Olivier's 'fix_mirror' branch for PR madgraph5#754 In particular a6731bd Olivier Mattelaer Wed Aug 23 13:23:12 2023 +0200 Merge branch 'fix_mirror' 2556cdd Olivier Mattelaer Wed Aug 23 09:27:38 2023 +0200 avoid that mirroring is reset by the plugin These lines fail the build (as well as clang formatting) [NOT OK] Check formatting in: pp_tt012j.mad/SubProcesses/P0_uux_ttx/CPPProcess.cc 786c786 < constexpr int helcolDenominators[1] = { 36,36 }; // assume nprocesses == 1 (madgraph5#272 and madgraph5#343) --- > constexpr int helcolDenominators[1] = { 36, 36 }; // assume nprocesses == 1 (madgraph5#272 and madgraph5#343) The same happens in each P subdirectory. Build errors: ccache /usr/local/cuda-12.0/bin/nvcc -Xcompiler -O3 -lineinfo -I. -I../../src -I/usr/local/cuda-12.0/include/ -DUSE_NVTX -gencode arch=compute_70,code=compute_70 -gencode arch=compute_70,code=sm_70 -use_fast_math -std=c++17 -ccbin /usr/lib64/ccache/g++ -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -Xcompiler -fPIC -c gCPPProcess.cu -o gCPPProcess.o gCPPProcess.cu(779): error: static assertion failed with "Assume nprocesses == 1" gCPPProcess.cu(786): error: too many initializer values 2 errors detected in the compilation of "gCPPProcess.cu".

valassi mentioned this issue Oct 21, 2021

Move latest eemumu developments from epoch1 to epoch2 ("merge" epoch2 into epoch1) #139

Closed

valassi changed the title ~~Add an example of a calculation with nprocesses>1~~ Add an example of a calculation with nprocesses>1 (eg pptt) Jan 20, 2022

This was referenced Jan 20, 2022

Fix assert in pptt code generation #340

Merged

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

Closed

Fix "nprocesses>1" code generation (example: uutt within pptt gives "const int denominators = 36,36;") #343

Closed

valassi changed the title ~~Add an example of a calculation with nprocesses>1 (eg pptt)~~ Add an example of a calculation with nprocesses>1 Mar 8, 2022

valassi mentioned this issue Mar 8, 2022

Disable mirror processes (nprocesses=2 in pptt) + Add process name to library names #396

Merged

valassi mentioned this issue Jun 15, 2022

JAMP2 dimensions - difference between MAXFLOW and NCOLOR? oliviermattelaer/mg5amc_test#21

Closed

valassi mentioned this issue Mar 31, 2023

Upgrade to Olivier's latest gpucpp branch upstream ("split_nonidentical_grouping") #619

Merged

This was referenced Apr 3, 2023

Fixes for SUSY code generation of gg_tt #624

Merged

fix susy gg_tt builds and add it to the repo #625

Merged

This was referenced Apr 3, 2023

Add SM gq to ttq (and gq to ttllq) - example of a process with DSIG1 and DSIG2 #626

Merged

My "vecsize" patches have broken mg5amcnlo "launch" for the default Fortran madevent #629

Closed

valassi added a commit to valassi/madgraph4gpu that referenced this issue Apr 5, 2023

[gqttq] in CODEGEN sigmakin template, replace nprocesses by codegen_n…

090ee11

…proc and codegen_procid (for sanity checks only madgraph5#272 and madgraph5#619)

valassi added a commit to valassi/madgraph4gpu that referenced this issue Apr 5, 2023

[gqttq] in CODEGEN sigmakin template, improve handling of codegen_npr…

0d32c1d

…oc and codegen_procid (for sanity checks only madgraph5#272 and madgraph5#619)

valassi added a commit to valassi/madgraph4gpu that referenced this issue Apr 5, 2023

[gqttq] in CODEGEN, remove most (not all) of the comments about "assu…

f179c5c

…me process.nprocesses == 1" (madgraph5#272 and madgraph5#343)

valassi added a commit to valassi/madgraph4gpu that referenced this issue Apr 5, 2023

[gqttq] regenerate gqttq sa and mad after cleaning up "nprocesses==1"…

bcfc44c

… comments madgraph5#272 and madgraph5#343

valassi added a commit to valassi/madgraph4gpu that referenced this issue Apr 7, 2023

[gqttq] in CODEGEN, improve the comment on nprocesses>2 for issues ma…

0033615

…dgraph5#272 and madgraph5#343 (see also PRs madgraph5#619, madgraph5#626, madgraph5#360 and madgraph5#396)

This was referenced Apr 7, 2023

Improve comments about nprocesses>1 #635

Merged

add pp_tttt to codegen and fix its builds (two P1 subdirectories which need different nwf values) #560

Merged

valassi closed this as completed Apr 7, 2023

valassi added a commit to mg5amcnlo/mg5amcnlo_cudacpp that referenced this issue Aug 16, 2023

[gqttq] in CODEGEN sigmakin template, replace nprocesses by codegen_n…

c123859

…proc and codegen_procid (for sanity checks only madgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#619)

valassi added a commit to mg5amcnlo/mg5amcnlo_cudacpp that referenced this issue Aug 16, 2023

[gqttq] in CODEGEN sigmakin template, improve handling of codegen_npr…

bacc669

…oc and codegen_procid (for sanity checks only madgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#619)

valassi added a commit to mg5amcnlo/mg5amcnlo_cudacpp that referenced this issue Aug 16, 2023

[gqttq] in CODEGEN, remove most (not all) of the comments about "assu…

de11f92

…me process.nprocesses == 1" (madgraph5/madgraph4gpu#272 and madgraph5/madgraph4gpu#343)

valassi mentioned this issue Aug 18, 2023

xsec from fortran and cpp differ in gq_ttq tmad tests (wrong order of couplings) #748

Closed

valassi mentioned this issue Jul 24, 2024

WIP add pp_tt to repo (plus obsolete fixes for bug 872 via reset_cumulative_variable, now fixed by Olivier via a single helicity filter) #935

Draft

valassi mentioned this issue Aug 5, 2024

Add support for nprocesses>2 (i.e. beyond mirror processes) in cudacpp to speed up directory handling? #951

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add an example of a calculation with nprocesses>1 #272

Add an example of a calculation with nprocesses>1 #272

valassi commented Oct 21, 2021

valassi commented Oct 21, 2021

valassi commented Jan 20, 2022

valassi commented Mar 8, 2022

valassi commented Jun 15, 2022

oliviermattelaer commented Mar 23, 2023

valassi commented Mar 31, 2023

valassi commented Apr 3, 2023

oliviermattelaer commented Apr 4, 2023

valassi commented Apr 5, 2023

valassi commented Apr 7, 2023

Add an example of a calculation with nprocesses>1 #272

Add an example of a calculation with nprocesses>1 #272

Comments

valassi commented Oct 21, 2021

valassi commented Oct 21, 2021

valassi commented Jan 20, 2022

valassi commented Mar 8, 2022

valassi commented Jun 15, 2022

oliviermattelaer commented Mar 23, 2023

valassi commented Mar 31, 2023

valassi commented Apr 3, 2023

oliviermattelaer commented Apr 4, 2023

valassi commented Apr 5, 2023

valassi commented Apr 7, 2023