inline_test_options

Julia

struct InlineTestOptions
InlineTestOptions(; model_name, alg, reltol, abstol, base_dir, initial_conditions, parameter_overrides, compiler)
InlineTestOptions(model_name::Union{Nothing, AbstractString}, alg, reltol::Union{Nothing, Float64}, abstol::Union{Nothing, Float64}, base_dir::Union{Nothing, AbstractString}, initial_conditions::Union{Nothing, AbstractDict}, parameter_overrides::Union{Nothing, AbstractDict}, compiler::Union{Nothing, Symbol})
InlineTestOptions(model_name, alg, reltol, abstol, base_dir, initial_conditions, parameter_overrides, compiler)

InlineTestOptions(; model_name=nothing, alg=nothing, reltol=nothing,
                  abstol=nothing, base_dir=nothing,
                  initial_conditions=nothing, parameter_overrides=nothing)

Per-document overrides for run_inline_tests , returned by its options_for callback.

Every field is optional, and a field left nothing INHERITS the value passed to run_inline_tests itself — so a callback that cares about one document’s solver and nothing else returns InlineTestOptions(alg=Rodas5()) and the rest of the run is unchanged.

This record exists so that site-specific policy stays at the site. A CI gate over a model corpus routinely carries basename-keyed tables — a stiff-solver map, an initial-condition seed for the documents whose tests do not state one — and each of those is a reason the gate could not call the library entry and re-implemented esm-spec §6.6 instead. One callback absorbs all of them without this module learning anything about the corpus.

initial_conditions / parameter_overrides are SEEDS: they are laid BENEATH each test’s own maps, so a test that states a value keeps it and a test that is silent gets the caller’s. They are merged with the test’s map before _scope_to_component runs, and so are keyed and resolved exactly like a test’s own keys — which is what makes the precedence well defined.

Source

TypeScript

Not available in TypeScript. TypeScript is outside the simulation capability profile (Julia, Python, Rust): build an RHS and integrate it; TypeScript and Go are deliberately non-simulating.

Python

Python does not export this type.

Rust

pub struct InlineTestOptions {
    pub model_name: Option<String>,
    pub solve: SolveOptions,
    pub base_dir: Option<PathBuf>,
    pub test_filter: Option<String>,
    pub initial_conditions: HashMap<String, InlineValue>,
    pub parameter_overrides: HashMap<String, InlineValue>,
    pub compiler: Option<Compiler>,
}

Per-document overrides for run_inline_tests_paths , returned by its options_for callback.

This record exists so that site-specific policy stays at the site. A CI gate over a model corpus routinely carries basename-keyed tables — a stiff-solver map, an initial-condition seed for the documents whose tests do not state one — and each of those is a reason the gate could not call the library entry and re-implemented esm-spec §6.6 instead. One callback absorbs all of them without this module learning anything about the corpus.

initial_conditions / parameter_overrides are SEEDS: they are laid BENEATH each test’s own maps, so a test that states a value keeps it and a test that is silent gets the caller’s. They are merged with the test’s map before scope_to_component runs, and so are keyed and resolved exactly like a test’s own keys — which is what makes the precedence well defined.

base_dir left None defaults to the document’s own parent directory, which is what anchors a §6.6.5 from_file reference at the .esm file rather than at the process’s working directory.

There is deliberately no cse field: unlike the Python binding, this crate’s problem builder exposes no common-subexpression knob — its CSE is unconditional internal machinery — and a field that silently did nothing would be worse than its absence.

Source · Rust docs

Go

Not available in Go. Go is outside the simulation capability profile (Julia, Python, Rust): build an RHS and integrate it; TypeScript and Go are deliberately non-simulating.