Skip to content

Physics Data Workflow

Physics data is part of the model. The practical workflow is:

text
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 result

Start From The Calculation

Identify the data needed by the particles and processes that can affect your observable:

CalculationRequired data
photon/electron/positron transportphoton, electron and relaxation data for every material element
photonuclear transportreaction cross sections, final-state products and owning secondary packages
proton or alpha rangematerial stopping tables over the full transported energy range
charged nuclear reactiontarget-nuclide cross sections and a declared final-state representation
neutron transportevaluated nuclides, temperatures, processing policy and any thermal binding law
decay sourcecomplete 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:

cpp
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:

cpp
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:

cpp
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.

NeoMC user documentation.