| | 1 | = Decay chains = |
| | 2 | |
| | 3 | == Major points == |
| | 4 | |
| | 5 | We want to be able to fully reuse the diagram generation routine with no modifications or additions. |
| | 6 | We want to be able to reuse different parts of the chain (main process/decay chain) independently. |
| | 7 | |
| | 8 | == Suggested solution == |
| | 9 | |
| | 10 | Define one process for each step in the decay chain: |
| | 11 | |
| | 12 | Main process (p p > h / p p > t t~) |
| | 13 | 1st decay (h > W+ W- / t > b W+, t~ > b~ W-) |
| | 14 | 2nd decay (W+ > q q~, W- > l- vl~) |
| | 15 | etc. |
| | 16 | |
| | 17 | Glue together vertices, correctly taking into account external particle number. |
| | 18 | |
| | 19 | == Issues == |
| | 20 | |
| | 21 | External particle number: The easiest way would be to simply check how many particles are in each decay chain, and shift the particle numbers of the processes accordingly. In p p > t t~ with full decay, give t number 3 and t~ number 6; in t > b W+, give t number 2, b number 3 and W number 4, and in W+ > q q~ give W+ number 3, q number 4 and q~ number 5; etc. The problem with this is that we now have t with number 2 in the decay process to be glued to the t with number 3 in the main process. |
| | 22 | The diagram generation algorithm always starts by combining particles 1 and 2, which means that the wave functions will not work nicely in multibody decays - we don't get the t as wavefunction, but rather a vertex with the last few particles. This could be partly fixed this would by reversing the order of the combinations, so that we always combine from the end rather than from the front, but that is not a complete solution, since we'll still have problems e.g. with t > e+ ve b, where the b first combines with the t to form a W. We would need to come up with some way to combine all other particles first, while leaving the combination with the decaying particle to last. |
| | 23 | |
| | 24 | Idea: Add new mode to combine_legs: so that, when it is a decay, generate_diagrams calls it with only the final state particles, and so that it will end not with an n->0 but with an n->1 where the 1 has to be the (inverse of) the decaying particle. |
| | 25 | Even better idea: Replace n->0 dictionary with {PDG for initial particle: PDG for initial particle}, and replace the Nclustered >= 2 requirement with Nclustered == 1 (exactly; otherwise t > gbW won't work). This will always work (?) as long as the decaying particle is not repeated among the final state particles (which is a requirement for a correct decay chain in any case). We can then simply remove the last (identity) vertex when we glue together the processes. |
| | 26 | Correct treatment of identical particles. This is not strictly a matter of diagram generation, but is needed to solve for the correct calculation of matrix elements. |
| | 27 | Idea: We only need to compare when 1. two particles in the same process are identical, 2. the final state particles for the two decay chains are identical and 3. the two chains have the same number of diagrams. Since the decay chain diagrams will have a particular structure where the combinations are always among final state particles, I think there should be a general way to compare diagrams. It doesn't matter if this is slow, since this will be done only a (very) few times. |
| | 28 | When is the combination done? I would suggest to do it immediately after diagram generation, at which time we should also get the expansion in number of processes due to multiparticle lables. |
| | 29 | How to represent decay chains? As in MG4, where a particular decay is associated with a particular external particle number, or as a list of processes, where p p > Z Z, Z > l+ l- means that both Zs will decay to l+l- while p p > Z Z, Z > l+ l-, Z > q q~ means that either (or the first) will decay to l+l- and the other (or the second) will decay to q q~? The advantage with the latter is that people won't be able to make the mistake of decaying only one of two identical particles, in which case they get a confusing factor 2 in the cross section. |
| | 30 | Comments (fabio) |
| | 31 | |
| | 32 | Regarding point 5. above, no chance should be given to the user to ask for something unphysical. |
| | 33 | |
| | 34 | Question (johan): So we should discard the present formalism (A>BC)? It is a nice formalism, clear and pretty well established at this point (I think). The alternative I can immediately think of would be something like |
| | 35 | p p > A B, (A > D E, D > F G, E > H I), B > J K L |
| | 36 | This way, for a process with identical particles, it is clear that |
| | 37 | p p > A A, A > B C D |
| | 38 | means that both As need to decay to B C D, while |
| | 39 | p p > A A, A > B C, A > D E |
| | 40 | means that the first A decays to B C and the second to D E. Actually this way of writing has the additional advantage that it becomes easy to make other specifications to the processes. |
| | 41 | Example: |
| | 42 | p p > go sq q $ go, go > t t~ n1 / t2, ul > u l+ l- n1, ur > u n1 |
| | 43 | where sq is a multiparticle label ul,ur, and I have specified that the core process doesn't allow the sq q to come from a go s-channel, and that the gluino decay to t t~ n1 can't be through a t2. So this notation would be very powerful. |
| | 44 | For the numbering of the particles: why not using a standard numbering for the final state particles and something conventional for the intermediate ones ( for example g[1] g[2] -> (t[-345] > b[3] (W[-45] >e+[4] v[5]) ) (t~[-678] > b~[6] (W[-78] >e+[7] v[8]) |
| | 45 | Once the problems outlined above are solved, it might be useful to write out a routine that can handle the full decay, or just the production then the decay processes, so that one has various possibilities to use it, in steps (like what Pythia would do at first) and then use the full matrix element to reweight the event and correct for the spin correlations and the off-shell effects...By doing this, also handling the various decay possibilities would be extremely simple and compact as only the decay currents would change allowing a very compact matrix.f |
