Physics Data Workflow
Physics data is part of the model. The practical workflow is:
choose a physical library and version
-> resolve the materials and nuclides used by the model
-> place the resulting data in a simulation package
-> run
-> retain provenance with the resultStart From The Calculation
Identify the data needed by the particles and processes that can affect your observable:
| Calculation | Required data |
|---|---|
| photon/electron/positron transport | photon, electron and relaxation data for every material element |
| photonuclear transport | reaction cross sections, final-state products and owning secondary packages |
| proton or alpha range | material stopping tables over the full transported energy range |
| charged nuclear reaction | target-nuclide cross sections and a declared final-state representation |
| neutron transport | evaluated nuclides, temperatures, processing policy and any thermal binding law |
| decay source | complete decay-data closure for the inventory nuclides |
Omitting a competing process table is not a safe way to disable that process. The package must support it, apply a deliberately selected model, or reject the calculation before histories begin.
Use A Resolver When One Exists
The coupled-EM resolver is the normal path for the supported reference data installation:
CoupledEmSimulationPackage em =
resolve_coupled_em_simulation_package(
CoupledEmDataLibraryDefinition{
.root = physics_data_root,
},
materials,
make_coupled_em_transport_config(profile),
make_coupled_em_material_process_config(profile));It resolves exactly the elements reachable from materials, constructs a coherent package, and retains the data-library version and source hashes. Photonuclear and other additional tables remain explicit.
For decay chains:
ResolvedDecayData decay = resolve_decay_data(
DecayDataLibraryDefinition{
.data_root = decay_data_root,
.data_version = "endf-b-viii.1",
},
inventory_nuclides);The decay resolver follows evaluated daughters to stable closure. Missing, ambiguous or mismatched files fail rather than producing a partial inventory.
For deuteron and triton stopping, the public light-ion resolver supports a deliberately selected same-velocity proton model with optional light-ion anchor correction. Its model name, scale and source hashes are retained in the simulation result.
Material Identity Comes First
Element-based EM data is resolved from material elements. Nuclear data is nuclide-specific. Thermal neutron data also depends on physical binding state and temperature:
MaterialInputDefinition water{
.name = "light-water",
.density_g_cm3 = 0.9970474,
.temperature_kelvin = 293.6,
.components = {
nuclide_atom_fraction(h1, 2.0, h1_mass),
nuclide_atom_fraction(o16, 1.0, o16_mass),
},
.thermal_scattering_bindings = {
ThermalScatteringBindingDefinition{
.target = h1_target,
.binding_state = "H_in_H2O",
},
},
};The binding state and nuclide ids are physical identities, not filenames. Resolvers own the mapping from those identities and the selected version to external files.
Lower-Level Importers
Use individual importers when you intentionally need a data combination not covered by a high-level resolver. Your application then owns:
- the library/version mapping;
- complete material and reaction coverage;
- consistency between photon, electron, relaxation and supplement data;
- source hashes and processing settings;
- the provenance stored with the result.
Transport never reads ENDF, HDF5 or reference-program objects directly.
Check The Result
Before preserving a score, inspect the provenance and support surfaces returned by the run:
coupled_em_data;light_ion_stopping_data;neutron_processed_data;neutron_support;- package result model and capability metadata.
Then compare the same observable, normalization and uncertainty with an appropriate reference. Agreement at the table-import level verifies data processing; it does not by itself validate the full transport result.