Feature: Add bottom/beauty hadrons support (particle lists + conserved “bottomness” charge, analogous to charm)

[vlvovch]

Motivation

Thermal-FIST has an extended/validated charm sector (muC, gammaC, charm-canonical ensemble). For further heavy-flavor studies, it would be valuable to support bottom/beauty hadrons in a comparable way.

Goals

• Add a bottom/beauty conserved charge (call it bottomness/beauty; symbol TBD to avoid conflict with baryon number B) throughout the core library.
• Provide bottom-extended particle lists (at least PDG2025) similar in spirit to list-withcharm.dat.
• Keep backward compatibility with existing 14-column list.dat format and all existing charm workflows.

Potential further goal

• Full generic-N conserved-charge refactor (can be a follow-up if scope grows).

Possible implementation plan

Phase 1 — GCE + lists (minimal viable)

1. Data model

   • Extend thermalfist::ConservedCharge with a new type (e.g. BottomCharge / BeautyCharge) and propagate to arrays/vectors sized by ConservedCharge::NumberOfTypes.
   • Extend ThermalParticle with bottom quantum number and absolute bottom content (analogous to Charm() / AbsoluteCharm()).

2. Thermal parameters

   • Extend ThermalModelParameters with bottom chemical potential and fugacity (names TBD; avoid confusion with muB baryon).
   • Update ThermalParticle chemical potential construction to include bottom contributions (like muC and gammaC paths).

3. List format / parsing

   • Current PDG2025 list.dat format is 14 columns:
     pdgid name stable mass degeneracy statistics B Q S C |S| |C| width threshold
   • Extend parser to optionally accept 16 columns with bottomness:
     ... S C Bbot |S| |C| |Bbot| width threshold (exact ordering/labels TBD)
   • Or do not add columns but infer bottom content from MCID.
   • Backward-compatible behavior: if bottom columns absent → bottom inferred from MCID.

4. Particle lists

   • Add input/list/PDG2025/list-withbottom.dat (and modular modular/list-bottom.dat if applicable).
   • Add bottom decay file decays-bottom.dat (and/or modular split) with catch-all channels if needed (mirroring charm list policy).
   • Update input/list/PDG2025/README.md to document the new list and any conventions (sign convention for bottomness, treatment of bottomonia with net bottomness 0 but |b|=2, inclusion/exclusion of B_c states, etc.).
   • Update input/list/PDG2025/generate_pdg2025.py if list generation should be automated (preferred).

Phase 2 — Canonical ensemble + UX integration (optional but desirable)

• Add bottom-canonical ensemble (analogous to ThermalModelCanonicalCharm) OR refactor to a generic “single-charge canonical” implementation reusable for S/C/bottom.
• Update event generator support (mirroring charm-canonical integration).
• Update GUI/fit tooling to expose bottom params when bottom hadrons are present.

Touchpoints / likely files

• Core charges & particle:
  • include/HRGBase/ThermalParticle.h (currently B,Q,S,C only)
  • src/library/HRGBase/ThermalParticle.cpp (gammaC/muC handling)
• Parameters/model:
  • include/HRGBase/ThermalModelParameters.h
  • include/HRGBase/ThermalModelBase.h, src/library/HRGBase/ThermalModelBase.cpp
• Canonical charm (template for bottom-canonical):
  • include/HRGBase/ThermalModelCanonicalCharm.h (+ corresponding .cpp)
• Particle list system:
  • include/HRGBase/ThermalParticleSystem.h, src/library/HRGBase/ThermalParticleSystem.cpp
    • Note: DecayTypeByParticleType() hard-codes “weak PDG” list and treats |S|/|C| as weak; bottom should be included similarly.
• Fit + GUI (Phase 2):
  • include/HRGFit/*, src/library/HRGFit/*
  • src/gui/QtThermalFIST/*
• Lists:
  • input/list/PDG2025/* (and possibly PDG2020/2014 variants)

Acceptance criteria

• Existing lists (14 columns) still load and reproduce current outputs.
• New bottom-extended list loads and bottom quantum numbers are visible in the particle table/API.
• Thermodynamic quantities correctly include bottom contributions via chemical potentials and fugacities.
• At least one automated test covers “load list-withbottom + sanity checks” (counts, one/two known species’ charges, etc.).

Open design questions

• Naming: bottomness symbol/field names vs baryon B (muB conflict).
• Sign convention for bottomness (align with PDG conventions and with existing charm/strangeness conventions).
• Inclusion policy for mixed heavy flavor states (e.g. B_c): include in both charm & bottom sectors or keep separate.
• Whether to implement bottom-canonical as a copy of charm-canonical or via a generic canonical-charge refactor.