Repository navigation
Conversation
…ry_service 0.5 data-model 0.6 renamed its fields and helpers to snake_case (detectorId to detector_id, mothersAreConsistent to mothers_are_consistent and so on) and moved the unit vocabulary from ship to SHiP. field_service 0.4 and geometry_service 0.5 moved into SHiP as well, with headers under SHiP/FieldService/ and SHiP/GeometryService/. ship::SHiPGeometryService is now SHiP::GeometryService. The C++ sources, the PyROOT checks in scripts/ and the docs use the new names, and CMake links SHiP::DataModel, SHiP::Units, SHiP::FieldService, SHiP::FieldServiceG4Adapter, SHiP::FieldServiceMapIO and SHiP::GeometryService. The pins move to shipdatamodel >=0.6, field-service >=0.4 and shipgeometryservice >=0.5, which drops the <0.6 cap. The installed aegir config now asks for SHiPDataModel 0.6. Nothing aegir writes changes on disk: the persisted classes are data-model's, and their names (SHiP::MCParticle and so on) are the same in 0.6. BREAKING CHANGE: aegir needs shipdatamodel >=0.6, field-service >=0.4 and shipgeometryservice >=0.5. Code reading aegir output must use the snake_case field names. Assisted-by: Claude Code:claude-opus-5-5
Part of standardising the ShipSoft C++ stack on one top-level SHiP namespace, after data-model, field_service, geometry_service and Shannon. Each application nests under SHiP rather than declaring directly into it. aegir's own code moves into SHiP::aegir, with the children lower_case below it: SHiP::aegir::clhep, ::hepmc and ::trace. The Geant4 code that lived in SHiP::g4 becomes SHiP::aegir::g4, and IGeometrySource moves from SHiP to SHiP::aegir, so only data-model, field_service and geometry_service now declare into SHiP itself. The plugin classes stay in anonymous namespaces, and geant4_module takes the Geant4 helpers it uses through using-declarations rather than a using-directive. The installed generator-source helper (aegir/mc_particle_source.hpp, CMake target aegir::source_helper) keeps its path and target name, but its declarations are now in SHiP::aegir. aegir-genie reopens namespace aegir to use it, so it has to move to SHiP::aegir::genie in step; there is no alias, because an alias cannot be reopened. Nothing persisted changes: aegir defines no ROOT dictionary of its own, and the classes it writes are data-model's. BREAKING CHANGE: aegir's C++ API is in SHiP::aegir rather than aegir, SHiP::g4 is now SHiP::aegir::g4, and SHiP::IGeometrySource is SHiP::aegir::IGeometrySource. Code built against aegir/mc_particle_source.hpp (aegir-genie) has to use the new names. Assisted-by: Claude Code:claude-opus-5-5
With data-model 0.6, opening aegir 0.4 output (data-model 0.5 classes) through RNTupleReader::Open(name, path) aborts in ROOT's RFieldMeta with "fStagingClass->GetClassVersion() == classVersion violated", so file_source could not re-simulate from existing files. data-model's I/O rules only apply once the file's streamer infos are known to ROOT, which needs the file opened through TFile first (root-project/root#23146, the same workaround data-model's own compatibility test uses). file_source now opens the TFile, keeps it alive for the reader's lifetime and attaches the reader to the RNTuple anchor. plot_muon_momentum.py and compare_rntuples.py open the TFile before reading too, since they are pointed at existing output. Checked against a 100-event gun_st_nofield_smoke output written on 2026-10-13 with data-model 0.5: file_source re-simulates five of its events, and compare_rntuples.py reads it. Before the change file_source aborts, as does a PyROOT read of the file that skips the TFile. Assisted-by: Claude Code:claude-opus-5-5
…ry_service 0.5 data-model 0.6 renamed its fields and helpers to snake_case (detectorId to detector_id, mothersAreConsistent to mothers_are_consistent and so on) and moved the unit vocabulary from ship to SHiP. field_service 0.4 and geometry_service 0.5 moved into SHiP as well, with headers under SHiP/FieldService/ and SHiP/GeometryService/. ship::SHiPGeometryService is now SHiP::GeometryService. The C++ sources, the PyROOT checks in scripts/ and the docs use the new names, and CMake links SHiP::DataModel, SHiP::Units, SHiP::FieldService, SHiP::FieldServiceG4Adapter, SHiP::FieldServiceMapIO and SHiP::GeometryService. The pins move to shipdatamodel >=0.6, field-service >=0.4 and shipgeometryservice >=0.5, which drops the <0.6 cap. The installed aegir config now asks for SHiPDataModel 0.6. Nothing aegir writes changes on disk: the persisted classes are data-model's, and their names (SHiP::MCParticle and so on) are the same in 0.6. BREAKING CHANGE: aegir needs shipdatamodel >=0.6, field-service >=0.4 and shipgeometryservice >=0.5. Code reading aegir output must use the snake_case field names. Assisted-by: Claude Code:claude-opus-5-5
Part of standardising the ShipSoft C++ stack on one top-level SHiP namespace, after data-model, field_service, geometry_service and Shannon. Each application nests under SHiP rather than declaring directly into it. aegir's own code moves into SHiP::aegir, with the children lower_case below it: SHiP::aegir::clhep, ::hepmc and ::trace. The Geant4 code that lived in SHiP::g4 becomes SHiP::aegir::g4, and IGeometrySource moves from SHiP to SHiP::aegir, so only data-model, field_service and geometry_service now declare into SHiP itself. The plugin classes stay in anonymous namespaces, and geant4_module takes the Geant4 helpers it uses through using-declarations rather than a using-directive. The installed generator-source helper (aegir/mc_particle_source.hpp, CMake target aegir::source_helper) keeps its path and target name, but its declarations are now in SHiP::aegir. aegir-genie reopens namespace aegir to use it, so it has to move to SHiP::aegir::genie in step; there is no alias, because an alias cannot be reopened. Nothing persisted changes: aegir defines no ROOT dictionary of its own, and the classes it writes are data-model's. BREAKING CHANGE: aegir's C++ API is in SHiP::aegir rather than aegir, SHiP::g4 is now SHiP::aegir::g4, and SHiP::IGeometrySource is SHiP::aegir::IGeometrySource. Code built against aegir/mc_particle_source.hpp (aegir-genie) has to use the new names. Assisted-by: Claude Code:claude-opus-5-5
With data-model 0.6, opening aegir 0.4 output (data-model 0.5 classes) through RNTupleReader::Open(name, path) aborts in ROOT's RFieldMeta with "fStagingClass->GetClassVersion() == classVersion violated", so file_source could not re-simulate from existing files. data-model's I/O rules only apply once the file's streamer infos are known to ROOT, which needs the file opened through TFile first (root-project/root#23146, the same workaround data-model's own compatibility test uses). file_source now opens the TFile, keeps it alive for the reader's lifetime and attaches the reader to the RNTuple anchor. plot_muon_momentum.py and compare_rntuples.py open the TFile before reading too, since they are pointed at existing output. Checked against a 100-event gun_st_nofield_smoke output written on 2026-10-13 with data-model 0.5: file_source re-simulates five of its events, and compare_rntuples.py reads it. Before the change file_source aborts, as does a PyROOT read of the file that skips the TFile. Assisted-by: Claude Code:claude-opus-5-5
ship-random 0.4.0 writes its multiply-adds as std::fma, so the same seed draws the same bits on every platform and with any compiler flags (ShipSoft/ship-random#11). Compared with 0.2, inexact uniform(lo, hi) / uniform53(lo, hi) ranges and gaussian with a nonzero mean can differ in the last bit on x86-64, so outputs are not bit-identical to runs made with ship-random 0.2. Since 0.3, ship-random installs its CMake version file with SameMinorVersion compatibility, so find_package accepts only the requested minor. The pixi spec is pinned to >=0.4,<0.5 and moves together with find_package(SHiPRandom 0.4). Assisted-by: Claude Code:claude-opus-5-5
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This branch has not been deployed
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
2 participants
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.
No description provided.