Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synced Polarizations and Spins #103

Closed
AntonReinhard opened this issue Jul 29, 2024 · 1 comment · Fixed by #112
Closed

Synced Polarizations and Spins #103

AntonReinhard opened this issue Jul 29, 2024 · 1 comment · Fixed by #112
Labels
06 - Feature-request Missing feature or functionality
Milestone

Comments

@AntonReinhard
Copy link
Member

It would be nice to add new indefinite spins and polarizations that sync polarizations or spins of different particles together. This would be helpful for example when considering multiple photons coming from a laser, where the polarizations are necessarily equal between the photons.
I suggest a type such as
SyncedPolarization{N} <: AbstractIndefinitePolarization, where N would be an integer to differentiate between multiple possible synced polarizations in the same process. For a process like kkke -> ke and the incoming Photons all having SyncedPolarization{1} set (and the other particles AllSpin/AllPol), there would then be only 16 total polarizations possible instead of 64 if AllPol had to be used for all particles. When generating code this makes a large difference, and because of intermediate result reuse, it is also better than generating the process with PolX and PolY once and summing.

It's conceivable to have an even more powerful implementation of such a type, allowing specific combinations of Pols/Spins, but I'm not sure if there would be any actual application of this.

@AntonReinhard AntonReinhard added the 06 - Feature-request Missing feature or functionality label Jul 29, 2024
@AntonReinhard AntonReinhard added this to the Release-next milestone Aug 6, 2024
@AntonReinhard
Copy link
Member Author

There is a problem with this new type, which is that it doesn't have a constant multiplicity. It may be better generally to remove or hide the current multiplicity and instead have it only defined on a whole process, but I'm not sure.

Otherwise, we could add a multiplicity member to the SyncedPolarization, which would then be the k-th root of 2, where k is the number of occurrences of the SyncedPolarization in the process.

@szabo137 Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
06 - Feature-request Missing feature or functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant