External optional link to FLUKA 2025#232
Open
afedynitch wants to merge 97 commits into
Open
Conversation
Member
Author
|
@jncots did you re-enable the failing tests? |
Collaborator
|
@afedynitch, all tests are enabled and "ignore warning" is deleted. The core problem is solved. I change the implementation of "Root(Writer)._write_buffers(self)" that caused the Future warnings. The previous implementation has reliance on undocumented features of uproot when The fix changes this automatic implicit initialization to explicit initialization of |
This reverts commit daa1fac.
This reverts commit 367d08b.
This reverts commit 3e5faec.
for more information, see https://pre-commit.ci
Design for a production-grade FLUKA model in chromo with hN/hA/AA, photohadronic, photonuclear, and EMD support; nuclear remnants in HEPEVT; CompositeTarget; ~32-test validation suite. Re-uses the existing draft on feature_fluka where possible, fixes the CHROMO_SGMXYZ typo, and relies on FLUKA's own routines for all conversions (MCIHAD/MPDGHA/KPTOIP/PDGION/SETION). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
24 bite-sized tasks covering install (scripts/install_fluka.sh), meson.build fixes, Fortran wrapper additions (pdg_to_proj_code, fluka_elem_properties, fluka_hepevt_summary, optional chromo_fill_remnants), CHROMO_SGMXYZ typo fix, Python rewrite, CrossSectionData.emd field, ~22-test validation suite, docs, and a time-boxed runtime-extension investigation. Each task is TDD-style where applicable with exact commands and expected output. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Idempotent installer: extracts FLUKA code + data archives under $FLUPRO, runs the top-level make, and verifies the five archives chromo links against. Reminds the user to persist FLUPRO in their shell rc. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace the hard-coded '../FLUKA/interface/dpmvers' relative path with $FLUPRO-relative resolution. Add fail-fast checks for the five FLUKA archives chromo links against, pointing users at scripts/install_fluka.sh. Refresh the fluka_syms list to match the planned Fortran wrapper additions (pdg_to_proj_code, fluka_elem_properties, fluka_hepevt_summary) and drop the unused fluka_key entry. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Function was assigning to CHROMO_SGMXY (missing trailing Z), leaving the declared function value undefined — Python-side cross sections returned garbage. Assign to the proper function name so SGMXYZ's return propagates correctly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Single entry point for Python->Fortran projectile code translation. Handles hadron/lepton via FLUKA's MCIHAD+KPTOIP, the photon as special external code 7, and nuclei by decoding PDG 10LZZZAAAI into FLUKA's A*10+Z*1e4+L*1e7+1e9 ion-coded form. SGMXYZ/EVTXYZ will call PDGION and SETION internally for the ion branch. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Post-STPXYZ accessor that returns Z, A, and AMSS for each registered material. Used by the Python wrapper to verify its pdg->fluka material-index map and by tests to assert that default + user-supplied targets landed in FLUKA's tables. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Counts HEPEVT entries by category: standard particles, light fragments (A<=4), residual nuclei (A>4). Lets tests assert that FLUKA's FLLHEP populates FHEAVY/RESNUC remnants into the HEP stack as PDG ion codes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Electromagnetic-dissociation cross section populated by FLUKA for charged hadron / nucleus projectiles on heavy targets. Defaults to NaN so models that do not populate it are unaffected. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace the 327-line draft. Key changes: - Trim _DEFAULT_MATERIALS to 9 entries (FLUKA STPXYZ GLBCRD limit = 10 regions) - Add guard raising ValueError when >10 total materials are requested - Add targets= kwarg for construction-time extension - Add _fluka_projectile_code via pdg_to_proj_code (hadron+photon+ion) - Route _cross_section through up to 3 channel-specific SGMXYZ calls - Populate CrossSectionData.emd - Add _check_kinematics bounds per-nucleon (hadron vs photon) - Resolve target material index in _set_kinematics (CompositeTarget-safe) - Use kin.ekin directly (kin.p1.mass not available on PDGID) - Defensive nucleus charge readout in FlukaEvent._get_charge - Clear remediation message when a target is not registered Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mirrors the Pythia8Cascade pattern. FLUKA's FLLHEP populates HEPEVT with GENSTK ejectiles and RESNUC residuals; beam particles are not placed at positions 0-1. FlukaEvent._prepend_initial_beam is a no-op. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduces the pytest module with run_in_separate_process helpers and a FLUKA-availability skip mark. Subsequent tasks fill in cross-section, event, and conservation tests. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Exercises the main FLUKA code paths for cross sections at 100 GeV ekin. Asserts σ_inel lies in physically reasonable mb ranges, monotonically increasing with A for p+A sweep. Also fixes Fluka._set_kinematics to handle CompositeTarget by using the first component for the initial material index (the base class _composite_plan calls _set_kinematics per-component during event generation, so the initial call just needs a valid placeholder). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Confirms chromo's base-class frame conversion feeds FLUKA equivalent kinematics regardless of whether the user supplied CenterOfMass or FixedTarget. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Covers the γ+p code path (PPHCHO) and γ+A (photonuclear at Δ and DIS regimes). Event test confirms nuclear remnants appear in the final state for γ+Pb at the Δ-resonance. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per-isotope decay-channel reader: returns branching ratios, daughter (A,Z,m), Q value, and a compact KIND code (1=alpha, 2=B-, 3=B+, 4=EC, 5=IT, 6=SF, 7=B-N, 8=B+P, 9=B-2N, 10=B-3N, 11=B-NA, 12=other) for each channel registered for (A,Z,m) in FLUKA's ISOTOP common. Also ships QRDDCY (Q-values for radioactive decay) verbatim from FLUKA 2025.1's dcytst.f harness. QRDDCY is user-supplied source in FLUKA's distribution and is NOT exported from libflukahp.a, so we embed it here to resolve the link reference from chromo_dcy_channels. Verified on Cs-137: two B- channels (kind=2,2) to Ba-137m (BR=0.947, Q=0.514 MeV) and Ba-137 g.s. (BR=0.053, Q=1.176 MeV); sum BR = 1.0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The pre-write br_ch(MIN(n_ch+1, max_ch)) before the n_ch>=max_ch guard left the last accepted slot holding a stale BR value when the caller passed an under-sized buffer. Reorder: kdcy lookup first, cap check next, then increment and write into br_ch(n_ch). New regression test test_dcy_channels_saturation_preserves_first_slot exercises max_ch=1 on Cs-137. Document the QRDDCY embed properly: add FLUKA-bump TODO with vintage "Last change on 25-Apr-26", and add a FLUKA_QUESTIONS.md entry asking upstream whether QRDDCY can be exported from libflukahp.a. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Expose per-isotope line lists (gamma, alpha, CE/Auger, beta+/-) sourced from FLUKA's blank-common SIGGTT pointer arrays. Energies are returned in MeV; the wrapper handles g.s. (NGMLNS/KGMLNS etc.) and isomer (NGMISM/KGMISM etc.) tables and the four datum widths (2 for gamma/CE, 3 for alpha, 4 for beta). The cap check (n_l >= max_l) gates the assignment, so an under-sized buffer cannot leave a stale value in the last accepted slot (mirrors the Task-4 fix). The 661.66 keV calibration line associated with Cs-137 is stored in FLUKA under the metastable daughter Ba-137m (im=1), not the Cs-137 g.s.; the smoke test queries Ba-137m accordingly. Note: SIGGTT is the REAL*4 view of the blank common, exposed via the AABLMD module. It is brought in transitively via (DBLPRW) -> (USFLMD) -> USE AABLMD; do NOT redeclare it locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The wrapper was overwriting e_l with the endpoint at offset +3, losing
the sign at offset +2 that distinguishes e+ from e-. Add a new output
array lpos_l (1=e+, 0=e-) so DecayLine.is_positron has a real source.
Also lock in the ndata=3 (alpha) and ndata=4 (beta) code paths with
new tests:
- test_dcy_lines_u238_alpha: U-238 alpha lines include ~4.20 MeV
- test_dcy_lines_cs137_beta: Cs-137 beta endpoints at 0.514 + 1.176
MeV, all lpos==0 (pure beta- emitter).
Update the design spec accordingly: SIGGTT is a REAL*4 module pointer
(not a function), and the positron sign lives in <E>'s sign, not BR's.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Spec inaccuracies caught in code review: - f2py exposes `_fluka.hepevt`, not `_fluka.hepcmm` (include file is (HEPCMM) but the COMMON block name is /HEPEVT/). - FLLHEP resets NHEP=0 on entry, so the Python sampling loop in Task 13 does not need an explicit HEPEVT scrub. - KDCY_OUT from chromo_dcy_sample is restricted to 1..6 even though chromo_dcy_channels returns 1..12; DCYFLG has no flags for compound channels (B-N, B+P, etc.). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Module-level _INITIALIZED guard shared between FlukaDecay and Fluka
(Fluka will mark init done after STPXYZ in Task 16, avoiding double
initialisation of FLUKA's decay tables).
- FlukaDecay.__init__: per-process singleton check, optional seeded RNG
via Ranmar (init_rng_state w/ temp file, mirroring Fluka._init_rng).
- FlukaDecay.lookup() accepts 'Cs137'-style names, (A, Z, m) tuples,
and PDG ion ids (10LZZZAAAI), returning a FlukaIsotope or None.
- _parse_isotope_name regex tolerates case-insensitive symbols and
the FLUKA isomer convention ('Tc99m'=m1, 'U238m2'=m2).
- Z->symbol fallback table covers Z=0..110 (free neutron through
darmstadtium, fully covers FLUKA's experimental decay catalogue).
Tests: 3 new (Cs137 by name, Tc99m isomer, tuple + missing); 14
existing keep passing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add lazy gamma/alpha/CE/beta line-list properties on FlukaIsotope backed by a per-kind dict cache and a new FlukaDecay._fetch_lines helper that wraps chromo_dcy_lines. Implement a DCYPRN-style __str__ that pretty-prints header + channels + the four line lists (truncating long lists at 10 rows). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Yields n correlated decay events per parent isotope by driving FLUKA's SPDCEV/FLLHEP through chromo_dcy_sample. FlukaDecay has no kinematics or frame, so events bypass FlukaEvent and are built directly from the HEPEVT common block into a fresh EventData (charge recovered from the PDG ion code for nuclei, like FlukaEvent._get_charge). Validates the parent up-front: unknown lookups and stables (FLUKA's T1/2 = 1e38 s sentinel) raise ValueError before any sampling. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Discovered while implementing FlukaDecay.chain (Task 15). Th-232 series chains terminate prematurely because SPDCEV returns LSUCCS=.FALSE. for Ac-228 even though the isotope has decay data in FLUKA's table. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fluka.__init__ gains a `post_event` kwarg: a callable invoked on every yielded event after frame boost and decay-handler validation. The canonical use is `DecayChainHandler(FlukaDecay()).expand` for chained radioactive decay of nuclear residuals. Implementation overrides `__call__` (since `_generate` returns bool, not an event) and snapshots HEPEVT into the MCEvent before the hook runs, so callbacks that themselves write to HEPEVT (SPDCEV) cannot corrupt the current event. After STPXYZ, `_mark_fluka_init_done()` flips the fluka_decay module guard so a subsequent `FlukaDecay()` constructed in the same process becomes a no-op (the singleton is hot already, calling chromo_dcy_init a second time would clobber STPXYZ's NMAT/MEDFLK setup). Three new tests in test_fluka_decay.py cover the three integration contracts: hook is called per-event, return value replaces the yielded event, and the default `post_event=None` path still emits the fragmentation residuals. The originally planned 50-event chain integration test is deferred: running `SPDCEV` for any beta emitter after `EVTXYZ` aborts in `lcendp.f:74` with an `EDPSCO` array bound check, even for isotopes that sample cleanly standalone. Logged as FLUKA_QUESTIONS.md #6.
Make FlukaDecay, FlukaIsotope, DecayChannel, DecayLine, DecayChainHandler, and STABLE_DEFAULT available at ``chromo.models.<name>`` (alongside Fluka and the other generators). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds the final acceptance suite for the FLUKA radioactive-decay interface: Th-232 chain produces at least one daughter nucleus per event, and Co-60 emits >=2 gammas in >=90% of decays (textbook ~99% via 1.17 + 1.33 MeV cascade through Ni-60*). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Polish pass on the FlukaDecay feature, addressing review findings: - FlukaDecay._seed_rng: register the temp RNG state file path on self._rng_state_file; __del__ unlinks it best-effort. Mirrors Fluka._init_rng's cleanup pattern, fixes a /tmp/ leak per process. - 3 new tests cover gaps that the final code review surfaced: test_lookup_pdg_ion_code (single-int PDG ion form), test_chain_custom_final_state_halts_at_daughter (U-238 -> Th-234 with custom final_state set), and test_chain_warn_on_max_depth (on_max_depth='warn' branch). - CLAUDE.md gains a 'Radioactive-decay interface (FlukaDecay)' section under FLUKA integration with a usage snippet and the post_event caveat. Total tests in test_fluka_decay.py: 37 (was 34). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Walkthrough of the new radioactive-decay interface: catalog filtering, isotope inspection (DCYPRN-style printout, channel/line dataclasses), inclusive sampling with Cs-137 beta + Ba-137m gamma spectrum and the Co-60 two-gamma cascade, plus decay chains with custom final_state and max_depth handling. Notebook is executed (energies in GeV, converted to MeV explicitly for nuclear-decay quantities). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PR #232's CI runs without FLUKA installed. Forcing "fluka" into enabled-models (added inadvertently in a836069) makes meson abort with "FLUPRO not set" on every CI build. Revert to the opt-in form: dev boxes with FLUKA installed must add "fluka" locally (or use a local override) but the committed file stays CI-safe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
chromo_dcy_sample now restores IPRODC=2 / MRTRCK=1 / MMTRCK in TRACKR before each SPDCEV call (per FLUKA author: IPRODC=2 must hold before every SPDCEV; MRTRCK/MMTRCK guard a secondary geoden.f:100 abort). This unblocks Fluka(post_event=DecayChainHandler(...).expand) for correlated isotopes; uncorrelated isotopes (Ac-228, ...) get a one-time warning and the chain branch terminates instead of silently continuing. Fluka.__init__ also refuses construction after FlukaDecay (unsupported order — first EVTXYZ aborts in evprtn.f:516). Tests cover SPDCEV-after-EVTXYZ for Cs-137/Co-60, uncorrelated Ac-228, the end-to-end Fluka+DecayChainHandler hook, and the construction-order guard. FLUKA_QUESTIONS.md / CLAUDE.md updated with the author responses; vendored QRDDCY cross-checked against the author-supplied dcytst.f snapshot (vintage 25-Apr-26). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fluka light-ion (He) event generation is unstable above ~14 GeV CMS (silent Fortran-level exit; pending full FLUKA upstream support for ion projectiles). Skip Fluka+He in test_generators, test_mass_shell, and test_cross_sections — alongside the existing Pythia8Angantyr He skip — instead of letting the worker crash. For test_rng_state, Fluka's Pythia8 decay handler runs an independent RNG (Pythia8 Mersenne, not FLUKA Ranmar) so its state diverges across the two reproducibility passes. Disable the decay handler for the Fluka path and use a 100 GeV p+p kin (Fluka p+p crashes silently above ~200 GeV CMS). For the bitgen variant, draw an int seed from the bitgen since Fluka._init_rng requires int(seed). Suite: 25 → 4 fluka failures. Remaining (test_final_state[Fluka], test_hepmc_io[Fluka], test_setstable[Fluka-*]) are pre-existing and unrelated to the He / RNG scope. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PPTMAX is set to evt_kin.plab and that's not the issue (raising it 1.1× or 2.0× doesn't help). Bisecting the silent p+p crash narrows the threshold to plab ≈ 20 TeV, exactly _transition_peanut_dpmjet — i.e. DPMJET-3 (which Peanut hands off to above the cut) aborts silently in this FLUKA build. Workaround for users who need higher CMS energies: pass transition_peanut_dpmjet=100*TeV at construction so Peanut keeps the path; verified to lift p+p to 250 GeV CMS (plab 33 TeV). Light-ion projectiles (d, t, 3He, 4He) push plab past the 20 TeV cut at modest CMS energies — He+p hits it at any CMS ≥ ~14 GeV. Drop them from Fluka._projectiles so Fluka(He, p, ...) raises ValueError from MCRun._check_kinematics rather than silently crashing. This makes the test_generators / test_mass_shell / test_cross_sections He-skip workarounds from the previous commit redundant — removed. CLAUDE.md updated with the DPMJET-3 cap + revised projectile constraints. pytest -n8 -k Fluka: 4 failed, 154 passed, 4 xfailed (was 4 failed, 136 passed, 18 skipped, 4 xfailed). Remaining failures unchanged and out of scope. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ssion Smoke test on satori (Rocky Linux 9, x86_64 FLUKA prebuilt) shows the exact kinematics that silently abort on the Mac arm64 prebuilt (plab=50 TeV, plab=200 TeV, p+O16 plab=50 TeV) generate clean events through the DPMJET-3 path with no STOP, no "0.000E+00 GeV" diagnostic, and no missing dt_*ini sub-init symptoms. Same FLUKA 2025.1 release, same DPMVERS=3.19.3.2, same chromo branch (feature_fluka, satori at 9231f27 — DPMJET dispatch is below those commits anyway). Pin the platform difference in the comments / docs so the workaround context is preserved: - src/chromo/models/fluka.py: rewrite the _projectiles comment to name the macm1234 archive as the regression source and the linux x86_64 archive as the working baseline. - CLAUDE.md: rewrite the "DPMJET-3 hadronic generator aborts" and "Light-nucleus and heavy-ion projectiles" bullets the same way, and note that lifting the workarounds is gated on a fixed Mac prebuilt. No code/behaviour change; just narrative. The defensive _transition_peanut_dpmjet=20*TeV default and the d/t/3He/4He projectile drop both remain — chromo dev/CI runs on Mac arm64, so removing those would silently kill workers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three new exported subroutines on the FLUKA side, used to bisect the
DPMJET-3 silent-abort issue from the Mac arm64 prebuilt:
- chromo_set_dpmjet_lpri(level): set LPri in (DTFLKA) so DT_KKINC's
reject path prints its diagnostic ("Requested energy ... exceeds
initialization energy ...") to fort.6 before the bare STOP fires.
- chromo_get_dpmjet_ehfl(lo, hi, amxp): read EHFLLO/EHFLHI/AMXPFR.
- chromo_set_dpmjet_ehfl(lo, hi, amxp): override the same. Confirmed
during the investigation that overriding these from outside does
NOT unblock the crash (DT_KKINC checks a different DPMJET-private
bound), but the helpers stay useful for any future state probing.
meson.build's exported-symbol list updated to keep the f2py wrapper
in sync.
FLUKA_QUESTIONS.md gains section #7, the question Anatoli sent the
FLUKA author: minimal F77 reproducer (no chromo wrapping), bisected
threshold (plab cross of _transition_peanut_dpmjet ~20 TeV), backtrace
at DT_KKINC.f:73, the "0.000E+00 GeV" diagnostic via LPri=10, the
post-STPXYZ (DTFLKA) state, the dt_init_ argument trace, and the list
of fixes that did NOT unblock (PPTMAX bumps, EHFLLO/EHFLHI overrides,
SGMXYZ-before-EVTXYZ, swapping in fluka_chromo's prinmvax/stpxyz.f).
A subsequent satori smoke test (recorded in commit d3feb2a) showed
the exact same kinematics run cleanly on the linux-x86_64 prebuilt,
so #7 is most likely a macm1234 binary regression rather than a
generic FLUKA library issue — pending author confirmation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace the meson `error()` calls in the FLUKA block with `warning()` + `fluka_ok = false`, then gate the _fluka extension build on `fluka_ok`. With this change, "fluka" can stay permanently in [tool.chromo] enabled-models — public CI without FLUPRO sees the warning, skips the _fluka build, and produces a working chromo wheel without FLUKA support. The CI footgun fixed in 9231f27 is no longer reachable. The warning text is the canonical install hint, repeated at every failure point (FLUPRO unset, FLUPRO dir missing, missing archives, missing libdpmjet*.a): For FLUKA support, build chromo from source with FLUPRO pointing at a working FLUKA installation (run scripts/install_fluka.sh). Runtime side: - common.py:MCRun.__init__ wraps the lazy `_library_name` import in a second try/except. If both `chromo.models.<lib>` and `<lib>` resolution fail and the subclass exposes an `_install_hint` attribute, re-raise ModuleNotFoundError with a friendly message ("chromo was built without <name> support … <hint>") instead of the raw "No module named 'chromo.models._fluka'". - Fluka._install_hint carries the same canonical hint as the meson warning, so a user who pip-installs a wheel without FLUPRO and then naively constructs Fluka(...) gets actionable guidance. Verified locally: - `meson setup build/cp312 --reconfigure` with $FLUPRO set: 50 build targets, "FLUKA DPM Version: 3.19.3.2" message, _fluka.so links cleanly (~50 MB), `Fluka(FixedTarget(100*GeV, 'p', 'p'), seed=42)` generates 2 events with NP=[6, 17]. - `env -u FLUPRO meson setup /tmp/.../no_flupro`: 47 build targets (3 fewer — wrap, fluka_all, _fluka), prominent yellow warning at meson.build:346 with the install hint. - Simulated missing _fluka via `sys.modules['chromo.models._fluka'] = None`: `Fluka(...)` raises ModuleNotFoundError carrying the full install hint. CLAUDE.md's FLUKA build section updated to reflect the new opt-in build flow (no more "fails fast" wording). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…e light-nucleus projectiles Apple's new linker (ld-prime, Xcode 15+) handles overlapping COMMON-block and weak symbols across the FLUKA archives differently from ld_classic. Under the new linker, DPMJET-3's (DTVARE) energy bound is left at zero and every event past the Peanut→DPMJET-3 transition is silently rejected (DT_KKINC.f:73 bare STOP — was FLUKA_QUESTIONS.md #7). Wire -Wl,-ld_classic into the _fluka link in meson.build, gated on a cc.has_link_argument probe so older toolchains and non-Darwin platforms get an empty link_args. With the fix in place: - Restore d/t/3He/4He to Fluka._projectiles (verified end-to-end: p+p CMS=1 TeV, p+O16 CMS=300 GeV, He+p CMS=1 TeV). - Mark FLUKA_QUESTIONS.md #7 RESOLVED with the workaround caveat (ld_classic is deprecated; will need a fixed prebuilt or alternate flag when Apple removes it). - Update CLAUDE.md FLUKA caveats accordingly. Also fix _cross_section so `prod` is populated whenever EITHER side of the collision is a real nucleus (previously only when the target was), which matches how downstream code keys on `prod` for AA kinematics. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…proton) FLUKA addresses photonuclear targets by element Z (STPXYZ takes IZELFL only, no mass number; EVTXYZ/SGMXYZ take only the material index). A free neutron is (A,Z)=(1,0): there is no Z=0 element and STPXYZ aborts "INVALID IZELFL". The previous izelfl=max(Z,1) clamp silently ran a proton for a "neutron" target (identical sigma_inel and pi+- spectra) — a misleading latent bug. _init_fluka_materials now raises a clear ValueError for PDG 2112. Documents the limitation as FLUKA_QUESTIONS Q8 (open question for Alfredo: is there a lower-level entry to pass the target nucleon directly?). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXojATD9AFKXDEPeBuWy8V
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
By linking chromo with FLUKA binaries, it is possible to use chromo for running the event generator inside FLUKA.
Limitations:
set_stable. Since chromo'sDecayHandleris enabled by default,Pythia8decay methods are used to decay the remaining short-lived particlespyproject.toml'senabled_modelslist.