search

oliviermattelaer / mg5amc_test

first attempt to move all bzr branch to git
Other
1 stars 1 forks source link

"Error: failed to reduce to color indices" in gg to ttg (only for event generation, not for cross sections) #14

Closed valassi closed 2 years ago

valassi commented 2 years ago

Hi Olivier, I am having some failures in my tests for gg to tt plus at least one gluon for instance ggttg (instead ggtt is ok).

NB I am getting this also with standard madevent in fortran...

From this repo 311 branch I produce a normal madevent run

generate g g > t t~ g
output pippo --vector_size=32
launch pippo

This works fine.

However then I go to the P1 directory and use the typical (no multichannel) input that I use for my tests

64 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)
0 ! Suppress Amplitude 1=yes (i.e. use MadEvent single-diagram enhancement)
0 ! Helicity Sum/event 0=exact
1 ! Channel number for single-diagram enhancement multi-channel (IGNORED as suppress amplitude is 0?)

Using that as input file in tmp, I do

cd pippo/SubProcesses/P1_gg_ttxg
 \rm results.dat 
 ./madevent < /tmp/avalassi/tmp.2BuWFo5V3p
 ./madevent < /tmp/avalassi/tmp.2BuWFo5V3p

The first madevent execution, which only prints out a xsec and writes out results.dat with the grid, is ok.

The second madevent execution fails with this as last line:

 Error: failed to reduce to color indices:

(By the way, it returns 0 as status code, it should return non 0 if it fails).

Any suggestion? Thanks! Andrea

valassi commented 2 years ago

(Just trying to do a checkpoint whether this is still needed. I do not see this issue in my tests now, but I think that it is because I am bypassing it, not because it is solved. I am only running the first part of the tests: I always delete results.dat before running my tests, an dthen things are ok for ggttgg. If I wanted to do not only cross section calculations but also event generation, then I would need to keep the existing results.dat, and then I think that this error would show up. So I guess this needs to be fixed eventually).

oliviermattelaer commented 2 years ago

I guess that setting multi-channel to False is pushing too much on the phase-space integrator and that it leads to some issue on some part of the phase-space. I do not face that issue with the normal run of the code. (or that some meta-data are not pass correctly in that case)

I can reproduce that behavior with the official version of the code, so I do not think that this is actually critical. Is that a blocker for you?

valassi commented 2 years ago

Hi Olivier, thanks a lot!

I confirm that this no longer appears if I use by default "suppress amplitude = 1". I guess I was using it equal to 0 to debug other issues, but now I can use 1 always. In any case I have the other option of using channel=0 to disable the enhancement factor.

This can be closed. I am now routinely doing both:

valassi commented 2 years ago

Sorry @oliviermattelaer I must reopen this. The details about how to reproduce this are a bit complex, see https://github.com/madgraph5/madgraph4gpu/pull/486. Essentially, even in "suppress amplitude = 1", I get this error in ggttgg and ggttggg when I only compare the cudacpp ME and I skip the SMATRIX1 computation of the Fortran ME. I suspect that there might be some info filled in through common blocks somewhere? I am having a look...

valassi commented 2 years ago

See logs in https://github.com/madgraph5/madgraph4gpu/pull/486/commits/d5a7a603ab12fcda7bd392bc1f1f9dd0ae30f39e#diff-ed50f3ccef2c94de76c78d7daba1e807078073b09d01087d517c5996910df0b7

oliviermattelaer commented 2 years ago

Hi, I guess it makes sense since the JAMP2 are then not populated. Did you include my sketch of program to select the color inside the cudacpp part? Then one need to adapt the fortran part (which is doing that selection for the moment) to just pick the choice from cudacpp.

valassi commented 2 years ago

Hi Olivier, thanks.

Hi, I guess it makes sense since the JAMP2 are then not populated. Did you include my sketch of program to select the color inside the cudacpp part? Then one need to adapt the fortran part (which is doing that selection for the moment) to just pick the choice from cudacpp.

Is it this one you refer to? https://github.com/mg5amcnlo/mg5amcnlo/commit/a809e2705e472e8665f6bef534bef0e40a3fbbb6

No I have not yet included that.

oliviermattelaer commented 2 years ago

Is it this one you refer to? mg5amcnlo/mg5amcnlo@a809e27

No I have not yet included that.

Yes exactly

valassi commented 2 years ago

Thanks but I am confused, I tried to generate my '--madgpu' option (ie madevent + your standalone_gpu as 2nd exporter, NOT madevent + my cudacpp as 2nd exporter) for ggtt and I seem to get no difference in generated code. Is this normal? I mean, is this a change in python code that will ease my life in code generation only, or are you generating some code differently?

oliviermattelaer commented 2 years ago

I'm moviing forward on a new handling of the color part (starting with https://github.com/oliviermattelaer/mg5amc_test/issues/19) but yes indeed this is not yet ready.

valassi commented 2 years ago

Ok no problem! Thanks I will keep this in mind then (and will move to that new github commit anyway).

valassi commented 2 years ago

Hi, I guess it makes sense since the JAMP2 are then not populated.

Very good now I see what you mean. I was getting confused but it totally makes sense. This is completely related to the random choice of color https://github.com/madgraph5/madgraph4gpu/issues/402.

Until/unless we implement that in cudacpp and in the bridge, I want to at least have a way out so that we still write events.lhe files, for instance where the 'randomly chosen color' is always 1.

I now see that all of the complex algorithmic of this is in addmothers.f. I will try to cook up a fake JAMP2 that I can pass to addmothers so that the algorithm proceeds and always chooses 1. I guess I just need to send an array where the first element is 1, and all other elements are 0...

valassi commented 2 years ago

Hi @oliviermattelaer finally I added a basic workaround in https://github.com/madgraph5/madgraph4gpu/pull/489

Essentially I implemented a 'dummy' color choice (all events have the same color). By setting JAMP2_MULTI(0,IVEC) to NCOLOR, this is enough for addmothers.f to avoid the crash and select a dummy color (I guess the first one available).

I am closing this.

valassi commented 1 year ago

For the record, I am working on the random choice of color and helicity https://github.com/madgraph5/madgraph4gpu/issues/402 https://github.com/madgraph5/madgraph4gpu/issues/403 The jamp2 will disappear from the bridge, so this issue #14 and my workaround will also normally disappear?

PS No I tried to simply remove the code where I was implementing the workaround for this #14 (otherwise my code was not building as JAMP2 is not defined in IMPLICIT NONE), but like this it segfaults in addmothers.f. This means that I must add a different workaround somewhere...