Particle ordering is important (?)

[mmikhasenko]

I love the API where you call the helicity angles by frame3.helicity_angles(momenta)

I wonder if (1,3) here should be (3,1) https://github.com/KaiHabermann/decayangle/blob/6c9e83dcf535b91b0f155a9964bac1230b20abe6/tests/test_lorentz.py#L229

since it is the angle of particle 3 in the rest frame of (31).

Example

(((12)3)4) vs (4((21)3)) would be the same tree, with different particle ordering.

I think it is very important to keep track of ordering, and introduce a proper language.

• same tree!
• same topology or different topology?
• different decay chains? - wight be a Wigner rotation of pi or 2pi between them

[KaiHabermann]

Right now ordering for node names ist simply smallest to larges integer. And for groups of nodes it ist longest to shortest and then smallest number to largest number.

I.e.

Nodes may be (1, 2, 3) (6,7) ...

A goup of nodes (allways two for the isobar model) may be ( (1, 2, 3), (8, 9) ) or ((1,2), 3)) or ((1, 3), 2)

Maybe another ordering scheme makes more sense. This was just an easy and consitent way to implement it.

[mmikhasenko]

I see, you say it is a kind-of a name that can be anything. (1,3) -> 3, 1 is specified explicitly somewhere else?

[KaiHabermann]

Not just a name. Its always going to be (1, 3) -> 1, 3. Here the helicity angles will be for the first daughter i.e. 1. First is defined by the ordering scheme outlined above.

[mmikhasenko]

I see. The advantage of your implementation is that everything should work correctly whatever ordering one takes. We should make sure that the choice of ordering is enabled for user. Usually, I prefer not flipping reaction plane when going through the chain. For 3b it means ((1,2),3), ((2,3),1), and ((3,1),2).

In the example,

    theta_rf, psi_rf = hel_angles[(1,3)]
    # dpd defines the angle to particle 3, but we chose the angle to particle 1
    # so we need to invert the angle
    assert np.isclose(dpd_helicity_2, np.cos(np.pi - theta_rf))

one can also check that the plane is flipped actually psi_rf = pi, and it won't be flipped with (3,1),

[KaiHabermann]

Do you have a code example, that would make a consistent ordering? or do you mean we simply order by 1, 2, 3 ... and roll over? What would be the expected outcome for a decay

0 -> (1,4), (3,5) Do we impose some kind of order for the two isobars then? Because right now this would also be undefined (both have the same length).

[KaiHabermann]

I tried, to come up with a soultion ,which would enable the ordering you suggested, but the issue is, that this kind of ordering need a lot more info, than the simple ordering I outlined above. And I am not sure, if an ordering, that needs more than the value of the node itself is a good thing :/

[mmikhasenko]

When thinking of 3b, the objective for indices was to have no azimuthal rotation. The solution then is to have even permutations of 1,2,3.

Your approach handles the arbitrary azimuthal rotations without hiccups, so it does not affect correctness. That is good. Therefore, the thing you need to consider is user experience. It should be straightforward to chose one convention, or another. Perhaps, it can be an argument of generate_trees function.

[mmikhasenko]

Alternative, is to introduce a method: impose_ordering(scheme), that would loop over the three.

[mmikhasenko]

@KaiHabermann

I miss understanding how your tolopogies[1] object looks like. Is it a tree? How does one see from this tree which particle is "number 1", which "number 2"?

if the nodes for 0->1234 decay are Node((1,2,3,4)), Node((1,3,4)), Node((1,3)).

Is it how you would store a decay topology?

[mmikhasenko]

looking at the code, I do not see how the decay topology would keep information of which particle is number 1 and which is number 2.

The other representation with brackets does distinguish it, (((12)3)4) vs (4((21)3)) would be the same tree, with different particle ordering.

I think it is very important to keep track of ordering, and introduce a proper language.

• same tree!
• same topology or different topology?
• different decay chains? - wight be a Wigner rotation of pi or 2pi between them

[KaiHabermann]

I store a topology as a literal tree. Meaning we have nodes with daughters. The ordering of the daughters is enforced by an ordering key, meaning a function, that takes a value and returns a value, by which this value should be sorted. Right now nodes can either have an integer value or a tuple of integers. When you create a node with a tupe value, the tuple will be sorted by smallest integer first When you have a set of nodes, like for a helicity angle, then the nodes are first sorted by length, with the longest coming first and then by value, where the smallest comes first.

this makes sure, that the Isobar consisting of (1, 2, 3) is always the same in terms of the order of particles. For a nbody decay going in permutations of 1,2,3,4,..n is possible, but not trivial in the current setup, which simply gives a value to each node independent of the underlying decay.

The order of a nodes daughters is thus allways the same, if the set of daughters remains the same. Independed of the decay.

[KaiHabermann]

Node ordering is configurable from the user now