Creating four-momentum objects using rapidity

[fstrug]

We can construct an example four-momentum objects with the following syntax:

particle = vector.zip({ 'pt' : [100], 'phi' : [0], 'eta' : [1], 'M' : [100]})

It would be nice to have functionality to substitute eta (pseudo-rapidity) with rapidity when creating four-momentum objects. I am wanting to include vector into our analysis, but the MC stores rapidity instead of pseudorapidity. Currently, we manually calculate px, py, pz, and E using pt, rapidity, phi, and mass. In principle, could the library support this? An example of the idea is shown below.

particle = vector.zip({ 'pt' : [100], 'phi' : [0], 'rapidity' : [1], 'M' : [100]})

[jpivarski]

In order to provide many coordinate systems, but prevent the number of combinations from exploding, was to factorize 4D space into three regions: the azimuthal plane (x-y, which may be perpendicular to a beamline), longitudinal (z, parallel with that beamline), and temporal. Starting with azimuthal, each new coordinate can mix with the previous ones, as "mass" is not purely temporal, for instance, but not the other way around. Then by multiplying linearly independent combinations of 2 azimuthal, 3 longitudinal, and 2 temporal coordinate systems, we have only 12 coordinate systems to worry about, and they compose in regular ways.

Pseudorapidity has no temporal component, but rapidity does, since it depends on the mass of the particle, so rapidity would break this rule. In your example, pt and phi are together purely azimuthal, but rapidity and M both mix all of the coordinate systems.

The reason why we're trying to keep the set of coordinate systems under control is because all of the "compute" functions need to be implemented for all coordinate systems. Adding a new coordinate system means implementing all of the compute functions again. Some of these implementations immediately convert to a canonical coordinate system and do the calculation there, as would probably be the case for one based on rapidity, but still, it would mean a lot of new functions, just for the redirection. (And I can't even tell how many new functions, since I don't know whether I would say that rapidity is longitudinal or temporal.)

Probably the best way to solve your problem is not to introduce new coordinate systems but to add a function to convert from pt, phi, rapidity, M to one of our existing 12 systems. Maybe, given rapidity and M, convert to eta and M and use that? I think that would minimize round-off error (and remember that we have double precision—many bits!—to work with).