Implement an interface for particle polarizations.

[Christian Speckner]

Please enlighten me if I'm wrong, but it appears there is no way to specify particle polarizations. I tried using "Hel" to cut on helicities, but all particles seem to be registered as unpolarized. Also, an extensions to "beams =" would be desirable in order to specify initial beam polarization in a more convenient way.

[Juergen Reuter]

Base for all ILC and muon collider features.

[Christian Speckner]

Update: I'm working in branches/speckner/polarizations on getting this implemented. As of r2438, it is possible to mark flavors as (un)polarized via the polarized and unpolarized keywords. However, it appears to me that by design it is impossible to cut on anything other than kinematical observables in the integration step - WK, please correct if I'm wrong? I'm now working on getting the polarization to propagate into the event record to allow for selective analysis of different helicities.

[Christian Speckner]

With r2439, r2440 and r2441, final state polarization is fully implemented in the branch and working. In order to get polarized particles in the final state, it is necessary to set the particles as polarized via polarized p1 [, p2, ...] and to set the flag ?polarized_events. Helicity can be accessed in the analysis step via the Hel observable. A small glitch is the fact that setting one member of a flavor product to polarized implies that all other members are treated as polarized as well, but I see no easy way to remedy this.

[kilian]

Fully agree, thanks!

Since I'm currently reorganizing integration/simulation at the command level (introducing an intermediate level of modules), in a different branch, please wait with merging your changes with the trunk. It might be better to merge them with the new branch first.

[Christian Speckner]

OK, I want to implement initial state polarization and do some extensive testing (especially to make sure I didn't break anything in the decay machinery) before merging anyways.

[Christian Speckner]

r2456 implements a syntax for specifying beam polarizations. Polarization is specified via beam_polarization = polarization_constructor [, polarization_constructor]

Each polarization_constructor can be one of

• none : unpolarized
• circular (fraction) : circular polarization
• transverse (fraction, phi) : transverse polarization
• axis (fraction, theta, phi) : explicit polarization axis
• longitudinal (fraction) : longitudinal polarization
• diagonal_density (h1:frac1 [, h2:frac2, ...]) : diagonal density matrix
• density_matrix (a, b : explicit 2x2 density matrix {{a, b}, {b*, 1 - a}}

Examples for possible setups:

beam_polarization = none
beam_polarization = circular (0.1), none
beam_polarization = circular (0.4), transverse (0.4, 20 degree)
beam_polarization = longitudinal (0.1), transverse (0.5, 30 degree)
beam_polarization = axis (0.3, 10 degree, 0.2), none
beam_polarization = density_matrix (0.1, 0.2 * exp (40 degree * I))
beam_polarization = none, diagonal_density (1:0.4, -1:0.1, 1:0.5)

If no one protests against this syntax, I will continue and tie this interface to the core next week.

[kilian]

Thanks for this work! It may interfere with the major rewritings for #258, so manual merging may become necessary, at least careful inspection. I'll review and merge once I got ssh connection again.

[Christian Speckner]

OK, then I'll wait with commiting the remaining changeset necessary for actually enabling the handling of initial state polarization.

[Christian Speckner]

As of r2481, WK's changes are merged into the branch and initial state polarization is complete and working. After some further testing, I'm ready to merge it into the trunk (and properly document it). The only change to the aforementioned syntax is the addition of beam_polarization = off which disables the feature (after enabling it).

For the polarization to actually be applied, beams have to be set up. beam_polarization can be used either as an option to the beams statement as in

beams = "e+", "e-" {
   beam_polarization = circular (1), circular (-1)
}

or globally / locally separate from beams, in which case it modifies both the existing and any future beam setup in respective scope. E.g., in

beams = "e+", "e-"
integrate (eeww) {
   beam_polarization = none, diagonal_density(-1:0.1, 1:0.9)
}
integrate (eeww)

the second integrate would use unpolarized beams, while both in

beams = "e+", "e-"
beam_polarization = none, diagonal_density(-1:0.1, 1:0.9)

and

beam_polarization = none, diagonal_density(-1:0.1, 1:0.9)
beams = "e+", "e-"

all consecutive integration and simulation passes would use the polarized setup.

The only remaining caveat (apart from some bugs I still have to track down) is the use of polarized decays in conjunction with unstable particles. I have yet to try it, but if the user first defines a decay (e.g. zuu = Z => u, ubar), then integrates it with beam polarization and finally sets the particle (e.g. Z) to unstable, then the polarized cross section and grids are going to be used in the decay chain which is definitely not intented. My solution to this would be to spit out a warning if such a case is detected, but I still am open for suggestions :)

[Christian Speckner]

Merged in r2491 after fixing some remaining issues. The only remaining tasks are some further testing and documentation -> closing this ticket.