Randomly pick one color for each event written to file (jamp2 handling)

[valassi]

Randomly pick one color for each event written to file (jamp2 handling)

Will give details elsewhere

[valassi]

Full details are given in #404.

This is on the critical path to get unweighted event sets to the experiments where each event has one color index (but it should not be needed for cross section calculations)

[valassi]

As I mentioned in oliviermattelaer/mg5amc_test#14 (comment), I would like to go about this issue in two steps:

• First, use a 'dummy' algorithm with a fake random choice of color, where each event gets assigned a (valid) color. In practice, JAMP2 must be filled with something that allows the addmothers algorithm to proceed, otherwise one gets the error 'failed to reduce to color indices' in "Error: failed to reduce to color indices" in gg to ttg (only for event generation, not for cross sections) oliviermattelaer/mg5amc_test#14
• In a second step, ensure a correct random choice of color. One option is to export all relevant JAMP2 through the bridge and use the Fortran addmothers algorithm as it is. Another option is to implement the random choice in cudacpp (this is the option that we said we would target, and @oliviermattelaer I think you are working on it...?).

[valassi]

About the design of the dummy algorithm, I am having a look at addmothers.f

• JAMP2 has dimensions (0:MAXFLOW, NB_PAGE_MAX): essentially, number of colors (plus 1!) and number of events per iteration

• The variable MAXFLOW is essentially NCOLOR? See discussion in JAMP2 dimensions - difference between MAXFLOW and NCOLOR? oliviermattelaer/mg5amc_test#21. Olivier mentioned that MAXFLOW may be bigger than NCOLOR. However, I have the impression that NCOLOR is really the relevant variable for the algorithms, ie the one used in loops, so I will concentrate on that and not on MAXFLOW.

• In particular, the variable nc in addmothers.f is taken from JAMP(0,IVEC) for event IVEC. This is initialized in the following way in code generation:

madgraph/iolibs/template_files/matrix_madevent_v4.inc:        JAMP2(0)=%(ncolor)d
madgraph/iolibs/template_files/matrix_madevent_v4.inc:    PARAMETER (NWAVEFUNCS=%(nwavefuncs)d, NCOLOR=%(ncolor)d) 

In my Fortran patch, I will therefore for the moment assume that JAMP2(0) is equal to parameter NCOLOR. (Suggestion: if this is the case, it would be better to specify this in the Fortran code, rather than relying on code generation to fill the same numerical value).

• The array ICOLAMP seems to be important in defining which colors are "valid" and which ones are not

      nc = int(jamp2(0, ivec))
      is_LC = .true.
      maxcolor=0
      if(nc.gt.0)then
      if(icolamp(1,lconfig,iproc)) then
        targetamp(1)=jamp2(1,ivec)
c        print *,'Color flow 1 allowed for config ',lconfig
      else
        targetamp(1)=0d0
      endif
      do ic =2,nc
        if(icolamp(ic,lconfig,iproc))then
          targetamp(ic) = jamp2(ic,ivec)+targetamp(ic-1)
c          print *,'Color flow ',ic,' allowed for config ',lconfig,targetamp(ic)
        else
          targetamp(ic)=targetamp(ic-1)
        endif
      enddo

• The targetamp here are essentially the cumulative probabilities of the random choice algorithm. Apparently their normalization is not important.

      xtarget=ran1(iseed)*targetamp(nc)

      ic = 1
      do while (targetamp(ic) .lt. xtarget .and. ic .lt. nc)
         ic=ic+1
      enddo
      if(targetamp(nc).eq.0) ic=0 

I should therefore be able to realtively easily design a dummy algorithm...

[valassi]

I have implemented the first step, a 'dummy' choice of color, in #489. This provides the workarund for oliviermattelaer/mg5amc_test#14

Note that in the end addmothers.f has its own way to set a dummy color, as long as JAMP2(0) is correctly set to NCOLORS, which is the only thing I have done.

The next step, doing a real random choice of color, will be more complex...