Note on color structure

[oliviermattelaer]

• The current selection of the color structure is currently done in addmothers.f
• The list of color that can be selectable for a given event is stored via the variable icolamp(ic,lconfig, iproc)
  • which is a list of True (color selectable) / False (color should not be assigned to the event)
  • ic is the color index
  • lconfig correspond to the topology/channel/diagram (not fully clear) used to generate the event (or used by MLM)
    • if no MLM is selected, the value of lconfig should be the same for the requested X events (but can change for each wrap/vector)
    • in case of MLM this might be event by event dependent
      • need to check that case (information might not be available yet --should be available--)
  • iproc correspond to the process selected for the (bunch) of events. (but can change for each wrap/vector)

Issue:

• is it possible to have only a single "channel" index?
  • replace the diagram number information by the channel number (in if statement/...)
• the size of lconfig is a specific one -> need to understand how this is related to the channel. This is the "real" channel number. (we likely need to set

Decision:

• replace the diagram index by a channel index (see pass amp2() to a list of size LMAXCONFIGS (number of channel) rather than MAXAMPS #19)
• update fortran signature to make the choice of color within matrix.f
  • do the change for helicity at the same time
• change the selection mode to the low memory one (at least as an option?)
• port the "icolamp" table to the export_cpp to have that table native in C++
• add an index in the bridge for the iproc (not fully sure if this is needed)

[oliviermattelaer]

How to choose the color/helicity:

Old method

• JAMP2 is a sum over helicity -> then do the sum of jamp2 -> picked according the the weight
• helicity is picked as TS(i) (following TS(I)/SUM)
• drawback non correlated choice (not a real problem)

LOW MEMORY code to pick one option (without having computed the full set of options)

  1. keep in memory
     - the running sum
     - the currently picked choice so far (initialised to the first possible one) 
  2. for a given new option with un-normalised probability x
  3.  pick the new option if "R<x/(x+sum)"
       - change random number to (x/(sum+x)-R)(sum+x)/x
  4. otherwise keep the previous option
       - change the random number to (R - x/(sum+x))(sum+x)/sum
  5. update the running sum     

New strategy without helicity recycling:

1. For each helicity use the low memory option to select which color to pick (for each helicity one can pick the same random number to pick the color
2. To pick the helicity use the low memory option to select the helicity (and update the choice of color accordingly)

New strategy with helicity recycling:

1. need to check if a single random number is not enough? and directly picked both helicity/color using the low memory option (memory gain here might be more limited here obviously)

@valassi, what do you think? for cpu, the low memory option is likely not needed (especially if we move to helicity recycling) for GPU this is likely useful.