lindhard/input/electron.rs
1//! The electron run description: one TOML document whose `[electron]` table
2//! describes the beam, the transport choices, the elastic and inelastic
3//! models, the per-material electron data and the tallies, next to the same
4//! `[materials]` and `[target]` tables as an ion run.
5//!
6//! This module only **exposes** what the library already does
7//! ([`crate::electron`], [`crate::tally::electron`]); it adds no physics. The
8//! schema is documented, with the rules for extending it, in `docs/cli.md`
9//! (section "Electron runs"). In short:
10//!
11//! ```toml
12//! [electron.beam]
13//! energy_ev = 10000.0
14//!
15//! [electron.transport]
16//! cutoff_ev = 50.0
17//!
18//! [electron.elastic]
19//! potential = "thomas-fermi-yukawa"
20//!
21//! [electron.materials.Si]
22//! optical_elf = "si_elf.toml"
23//!
24//! [target]
25//! substrate = "Si"
26//!
27//! [run]
28//! histories = 1000
29//! seed = 1
30//! ```
31//!
32//! [`ElectronInput::resolve_in`] validates the description, reads the data
33//! files it names and checks their provenance with the loaders of
34//! [`crate::electron::data`] (an optical ELF without a provenance is refused;
35//! so are band, phonon and polaron parameters without one), and returns the
36//! engine's types ([`ResolvedElectron`]). Building the cross-section tables
37//! and running the transport is the caller's (`lindhard-cli`).
38//!
39//! Like the ion input, every table rejects unknown keys and the echoed input
40//! ([`ResolvedElectron::input`]) has every default filled in, so a result can be
41//! reproduced from its own header.
42
43mod resolve;
44mod resolved;
45mod schema;
46#[cfg(test)]
47mod tests;
48
49pub use resolved::{
50 DataFile, ElasticChoice, ResolvedEPair, ResolvedElectron, ResolvedElectronMaterial,
51 ResolvedInnerShells,
52};
53pub use schema::*;