Preserve resonance histories in event output

[Juergen Reuter]

Tackle the infamous problem to conserve the invariant masses of intermediate resonances when passing partons as shower systems to the parton shower.

[kilian]

Accepting.

To put things in order: the barebone of this ticket is to identify all possible resonance histories for a given momentum configuration and assign probabilities to them. I assume that this is not a well-defined problem. At first guess, I'd limit the probability of a resonance being relevant off-shell to a certain multiple of the width, for instance. That would be a cut-off function, probably with some free parameter.

Roughly speaking, the matrix element for a resonance could be estimated by applying a fudge factor, canceling the Breit-Wigner denominator. Might involve an on-shell projection for the momenta, though. We also could get on-shell matrix elements by separate calls to OMega, if absolutely necessary.

[Juergen Reuter]

MG5 has such a parameter to cut off resonance Breit-Wigners. The default is that everything beyond 3*Gamma is set to zero. Of course, when we really produce resonances on-shell to quantify weights of different histories, does one take on-shell processes into account, or would one like to fold in BRs?

[kilian]

So far, I added code to the phase-space modules such that I can extract the resonance set from the phase-space configuration. This used to be possible from the cascades set (I reused that code, partly), but doing it directly from the phs forest is more convenient.

A side-effect is that now particle and antiparticle are distinguished in phase space, if they appear as s-channel resonances. This matters, for instance, in 4f production via W+W-, and it is a real improvement if the decay is semileptonic, so there is an actual difference depending on resonance charge.

In processes where this matters, the numbers have changed somewhat due to the (unchanged) phs channels being distributed among a larger number of groves. The resonance_histories branches contain according patches for a few unit and functional tests.

Question is, can this have unwanted consequences? There will be an effect on the ttbar threshold runs, although I don't expect any statistically significant changes. So far, I didn't merge anything into the master.

[Juergen Reuter]

Discussion at DESY: please open Merge request. Then we can discuss the merge request on gitlab.

[Juergen Reuter]

Milestone renamed

[kilian]

This now under way. Creating the resonance info is done, actually using it is WIP.

[kilian]

Process configuration and resonance calculations are mostly done; last item will be to actually modify the generated events based on kinematics and matrix elements.

Temporarily ranking down in favor of #819.

[Juergen Reuter]

This is now mainly implemented, and also mostly validated. The documentation for the manual is mainly there, but needs to be merged into the master/trunk. Then, the only (known) open issue is the thing with having more than one process in the SINDARIN.

[Juergen Reuter]

All open things have been fixed in r8044. There are one or two unit tests and five functional tests. Everything works included structured beams and also with several processes in the SINDARIN file. Closing.