Skip to content

fix: R-parity of squarks and sleptons - #811

Open
syahra712 wants to merge 1 commit into
scikit-hep:mainfrom
syahra712:fix-susy-r-parity
Open

syahra712 wants to merge 1 commit into
scikit-hep:mainfrom
syahra712:fix-susy-r-parity

Conversation

@syahra712

Copy link
Copy Markdown

r_parity gives +1 for squarks and sleptons, but the docstring (and physics) says SUSY partners have R = -1. Gauginos are already right.

>>> from particle import Particle, PDGID
>>> Particle(PDGID(1000001), "~d(L)").r_parity     # squark
1
>>> Particle(PDGID(1000011), "~e(L)-").r_parity    # slepton
1
>>> Particle(PDGID(1000022), "~chi(1)0").r_parity  # neutralino
-1

Cause: R = (-1)^(3B + L + 2s) uses baryon_number and lepton_number. These only look at is_quark / is_lepton, which cover IDs 1-8 and 11-18. So a squark ends up with B = 0, a slepton with L = 0, and with s = 0 the exponent is even.

Fix: squarks and sleptons carry the B and L of their SM partner. A small _sm_partner_pdgid helper maps a SUSY ID like ±1000001 / ±2000013 to ±1 / ±13, and baryon_number / lepton_number check that. Non-SUSY IDs are unchanged.

Tests: added test_r_parity_susy_particles, which covers squarks, sleptons, a sneutrino, the gluino, a neutralino and a chargino.

  • It fails on main for the five squark/slepton cases and passes with the fix.
  • The rest of the suite passes. The exception is test_generation.py::test_generate, which fails the same way on main with my local pandas.

I also added a changelog entry under WIP.

AI-assisted (Claude): I used it to help read the code and draft the test. I reviewed and ran everything myself.

@eduardo-rodrigues

Copy link
Copy Markdown
Member

Can you cite your physics sources? Also, if indeed some use-case was not accounted for, which is not that surprising since we haven't focused much on SUSY, then this helper should not be needed provided the overlooked bits get sorted at source, no? The helper seems to be going around the issue rather than addressing it at source. What do you think?

(And don't give me an LLM reply as I like to exchange with human contributors, not bots.)

@eduardo-rodrigues

Copy link
Copy Markdown
Member

Hello @syahra712, did you think about the issues at source to extend the lepton/baryon number functions to accurately account for SUSY particles? Let me know if you are interested to finalise this work in the best way possible.

@syahra712

Copy link
Copy Markdown
Author

Hey @eduardo-rodrigues you're right and yes i want to finish it properly, i did got a channce to look deeper into it.
On sources: R-parity is R = (−1)^(3(B−L)+2s). Martin’s SUSY Primer (hep-ph/9709356) covers it in the R-parity section, and it goes back to Farrar & Fayet, PLB 76 (1978) 575. A superpartner sits in the same supermultiplet as its SM partner, so it has the same B and L and only the spin shifts by ½. So squarks have B = ±1/3, and sleptons and sneutrinos have L = ±1. The current docstring form (3B + L + 2s) gives the same result, since the exponents differ by 4L. The formula’s fine; B and L just come back as 0 for squarks and sleptons.

On the helper part i would agree, it’s working around the real gap. pdgid has no way to say “this is a squark/slepton”.

What i would propose as a plan for it is to Add is_squark / is_slepton to pdgid/functions.py next to is_quark / is_lepton: is_SUSY plus a fundamental-ID check (1–6 and 11–16), wired into PDGID like the others. j_spin() already handles SUSY this way from what i saw, so it might fit the module.
baryon_number / lepton_number then just check is_quark or is_squark and is_lepton or is_slepton, and the helper goes away.
Addig pdgid-level tests on top of the existing R-parity ones.

Two quick questions i had eduardo, are you OK with those names? And should we go with 4th-gen partners count? I left them out as in nnow because 1000017/18 are already special-cased as neutral.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants