FAQ

Is NeoMC a finished application?

No. NeoMC is primarily a C++ transport core library. It also has a reusable application layer, but the repository executables are currently benchmark consumers rather than one universal user-facing CLI.

Should I use benchmark executables as the main API?

No. They are useful reference consumers, but the reusable surfaces are the public headers under include/neomc/*, especially source/, simulation/, transport/, tally/, and application/.

Which transport packages are implemented?

The package registry currently lists implemented coupled_em, proton, alpha, and neutron packages. Their maturity differs:

• coupled_em: approximate photon / electron / positron coupled EM transport
• proton: approximate CSDA electronic stopping
• alpha: approximate CSDA electronic stopping in the current ASTAR-water scope
• neutron: experimental data-driven free flight with total / elastic / capture data

Do not read this as full hadronic, ion, or production neutron physics.

What decay emissions are represented?

Static decay inventory sources can represent photon, electron, positron, proton, neutron, and alpha emission rates. Transport execution then depends on which packages are enabled for the session.

Can one decay history emit more than one transport particle?

Yes. A static decay inventory source can emit a batch of source sites for the same history. Mixed transport partitions that batch by owning package.

Why do benchmarks require importers?

Current benchmark executables depend on importer-backed physics data. CMakeLists.txt rejects NEOMC_BUILD_BENCHMARKS=ON unless NEOMC_BUILD_IMPORTERS=ON.

How do I verify mixed-source routing?

Build benchmarks and run:

./build/neomc_mixed_decay_transport reference --histories 50

That benchmark exercises mixed decay emission, package partitioning, source-rate reporting, unified tally accumulation, and energy-balance closure.