Repository navigation
Support pentaquarks and tetraquarks now that the PDG changed their numbering scheme, making it stable #804
Description
charge / three_charge return the wrong value for the 7-digit pentaquark codes. The two examples listed in the PDG Monte Carlo numbering scheme come out wrong:
from particle.pdgid import charge, three_charge, is_pentaquark
for pid, name, expected in [(9221132, "Theta+", 1), (9331122, "Phi--", -2)]:
print(pid, name, is_pentaquark(pid), three_charge(pid), charge(pid), "expected", expected)Output:
9221132 Theta+ True -3 -1 expected 1
9331122 Phi-- True 0 0 expected -2
The PDG scheme (RPP 2020, "Monte Carlo Particle Numbering Scheme", item 6f) says for pentaquarks nr nL nq1 nq2 are the four quarks and nq3 is the antiquark, and the table lists Theta+ = 9221132 and Phi-- = 9331122. So 9221132 is u u d d sbar (+1) and 9331122 is s s d d ubar (-2). The is_pentaquark docstring describes the same layout.
Likely cause: in three_charge (src/particle/pdgid/functions.py, around line 689) pentaquarks go through the normal baryon branch, which adds q1 + q2 + q3 as three quarks. So nr and nL are ignored and the antiquark nq3 is counted as a quark. The test ID 9422144 happens to give the right answer (+1) by coincidence, so the tests don't catch it.
Versions: particle 1.0.1 (PyPI) and main at 1e729ff, Python 3.12, macOS.
Activity
eduardo-rodrigues commentedon Oct 1, 2026
Hello. Thank you for the report. I am not too surprised as pentaquarks and tetraquarks aren't fully supported, reason being that things weren't stable until recently. Now, since not that long, we have a scheme to name them, for example.
Let me know if you would like to work on this. Otherwise I will get to it soon - your report bumps up the priority.
eduardo-rodrigues commentedon Oct 1, 2026
Note that you should be referring to the 2026 version https://pdg.lbl.gov/2026/reviews/[rpp2026-rev-monte-carlo-numbering.pdf](https://pdg.lbl.gov/2026/reviews/rpp2026-rev-monte-carlo-numbering.pdf), not the old 2020 version, which got superseded. Your post seems straight from an LLM with no physics knowledge. Did you actually play with the package and have interest in it?
So the numbering scheme has changed and the above is obsoleted. My point that I need to support the new scheme remains, though.
shaneraphel commentedon Oct 5, 2026
I would like to work on this. I read the 2026 MC numbering review (section 15): pentaquarks are 9-digit codes 1 nr nL nq1 nq2 nq3 nq4 nq5 nJ with the first four quarks sorted descending and the fifth the antiquark, and the old 7-digit Theta+/Phi-- entries were removed from the tables. My plan: decode the quark/antiquark digits directly for the 9-digit layout in three_charge (charge = q1+q2+q3+q4-q5 over the digit charges, keeping the existing sign convention for antiparticles), with regression tests built from the 2026 codes 100221132 and 100331122. I will leave tetraquarks and the legacy 7-digit codes untouched unless you prefer otherwise.
shaneraphel commentedon Oct 5, 2026
Small correction to my plan above: while implementing I found the legacy 7-digit IDs and the new 9-digit IDs decode with the same digit formula (four quark digits minus the antiquark digit), so the patch also corrects the legacy values — 9221132 now gives +1 and 9331122 gives -2 instead of the reported -1/0. No existing tests pinned the old values. If you would rather keep the legacy path byte-for-byte untouched I can drop that hunk and keep only the 9-digit support.
Support RPP-2026 9-digit pentaquark codes in is_valid/three_charge (fix
[-]charge() is wrong for pentaquark PDG IDs (Theta+ gives -1, Phi-- gives 0)[/-][+]Support pentaquarks and tetraquarks now that the PDG changed their numbering scheme, making it stable[/+]eduardo-rodrigues commentedon Oct 5, 2026
Thank you @shaneraphel for your interest. Out of curiosity, what is your background? Are you a user of this package?
Indeed the relevant thing at this point is the support of the new PDG scheme for pentaquarks and tetraquarks, which are established and the PDG reworked the numbering scheme for them. So the Theta+/Phi-- entries "from history" are irrelevant and to be removed, which means the legacy scheme should go as well to avoid any confusion.
I will try and find time this week to review your related PR. I hope you navigated the package to see the general structure, requirements on documentation, where to put tests and some example particles for tests (https://github.com/scikit-hep/particle/blob/main/tests/utils/pdgids.py). That will make the review more efficient.
It would also be great to deal with tetraquarks in the same enhancement since both are exotics, and the support was worked out by the PDG at the same time. One should also add a is_tetraquark function similar to is_pentaquark, the latter existing already.
shaneraphel commentedon Oct 5, 2026
thanks for review,i will stay tuned for the new version.
Support RPP-2026 pentaquark and tetraquark numbering, drop legacy sch…
shaneraphel commentedon Oct 5, 2026
Thanks for the steer — I've reworked the PR accordingly (same PR #806, force-pushed):
is_pentaquarkpredicate, itsthree_chargebranch, thehas_*special case, the test fixtures, and the "pentaquarks are baryons" test. The old codes (9221132/9331122/9422144) are explicitly asserted as not-pentaquarks now.is_tetraquark(plusPDGIDproperty and export) implementing the section 14 sorting rules including the antiparticle exception, with validity and charge support. Test fixtures use the review's own Tc/Tb table entries, and I hand-checked their charges.info()expectations updated for the new function.One thing I deliberately left alone:
is_hadronstill excludes extra-bits codes (so 9-digit exotics report False there, as before) — happy to extend it if you'd like exotics counted as hadrons.eduardo-rodrigues commentedon Oct 5, 2026
I approved the CI tests to run. If coverage is good then some tests should fail because these exotics are of course hadrons - made of quarks and/or antiquarks. Otherwise that should hint you at what to fix ...
You did not reply to my question above: Out of curiosity, what is your background? Are you a user of this package?
Thanks for the work.
shaneraphel commentedon Oct 5, 2026
I am a user of this package,I am a independent research.
eduardo-rodrigues commentedon Oct 29, 2026
Dealt with (and beyond) and closed via PRs #810, #816, #817, and commit 402f2b0.