Source: https://guthlabs.ai/docs/instruments/ode-solver-euler-rk4-rk45/

instrument / verified-clean

# ODE Solver (Euler / RK4 / RK45)

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Inspectable records

[01**Overview**Purpose and lifecycle](<https://guthlabs.ai/docs/instruments/ode-solver-euler-rk4-rk45/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/ode-solver-euler-rk4-rk45/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/ode-solver-euler-rk4-rk45/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/ode-solver-euler-rk4-rk45/qualification/>)

## Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

**Area**: Mathematics — arithmetic through advanced (algebra, matrices, calculus, sequences/series, number theory, combinatorics, graphing, complex numbers, geometry, logic, sets)

**Tranche**: tranche-6

**Evidence ID**: t6-026

**Ledger rows**: 1

No ledger note is attached.

## Review findings

The stated methods are standard and the fixed-step test vectors are correct. The specification needs the exact Euler and RK4 formulas plus a complete Dormand-Prince RK45 error-control contract before the implementation can be verified as deterministic. The honest label is appropriate but should explicitly mention truncation error, tolerance semantics, and possible failure on stiff or nonsmooth problems.

### Formula and scope findings

- Euler is named as a supported method, but its formula is not specified. The standard update should be y_{n+1}=y_n+h f(x_n,y_n).

- RK4 is described too vaguely to verify implementation details; the standard method requires k1=f(x_n,y_n), k2=f(x_n+h/2,y_n+h k1/2), k3=f(x_n+h/2,y_n+h k2/2), k4=f(x_n+h,y_n+h k3), followed by y_{n+1}=y_n+(h/6)(k1+2k2+2k3+k4).

- RK45 is not fully specified: Dormand-Prince coefficients, embedded fourth- and fifth-order estimates, error norm, safety factor, step-size controller, minimum and maximum step sizes, and endpoint handling are all omitted.

- For systems, f(x,y) must explicitly support vector-valued y and componentwise vector arithmetic; this is not stated.

- The claim of step-size control needs an explicit acceptance/rejection rule and a termination condition.

### Unit assumptions

- x and the independent-variable step h use the same units.

- y and f(x,y) use compatible units, with f having units of y per unit x.

- The Euler test uses t in seconds, y in metres, and f=1 metre/second.

- Numerical tolerances are dimensionless only if the implementation uses normalized or relative error; otherwise their units and scaling must be specified.

- The vectors use real-valued, nonstiff problems with finite function evaluations.

## Boundary hardening

### Recorded hazards

- A zero, negative, NaN, or excessively large step size can cause invalid progression or nontermination unless explicitly rejected.

- Adaptive control can divide by zero or produce an undefined next step when the estimated error is zero; the implementation needs a defined zero-error step-growth rule and a maximum step size.

- Absolute-only error control can accept poor results for large-magnitude states, while relative-only control can fail near zero; the error norm and scaling must be specified.

- Discontinuous, non-Lipschitz, or undefined f values can invalidate convergence assumptions.

- Stiff systems may require implicit methods; the current honest label mentions stiffness but does not state that explicit Euler, RK4, and Dormand-Prince can fail or become impractical.

- Backward integration, interval endpoints not divisible by h, and rejected adaptive steps need explicit handling.

- Systems require componentwise absolute/relative tolerances or a clearly defined vector norm.

## Errata and corrections

No applied erratum is attached to this unique-name record.

## Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

````
{
  "inputs": {
    "method": "Euler",
    "f": "dy/dt = 1 metre/second",
    "initial_condition": {
      "t": 0,
      "y": 0
    },
    "interval": [
      0,
      1
    ],
    "step_size": 0.25,
    "units": {
      "t": "second",
      "y": "metre"
    }
  },
  "expected_outputs": {
    "trajectory": [
      {
        "t": 0,
        "y": 0
      },
      {
        "t": 0.25,
        "y": 0.25
      },
      {
        "t": 0.5,
        "y": 0.5
      },
      {
        "t": 0.75,
        "y": 0.75
      },
      {
        "t": 1,
        "y": 1
      }
    ],
    "final_y": 1
  },
  "working": "Use y_{n+1}=y_n+h f(t_n,y_n), with h=0.25 second and f=1 metre/second. Start y0=0. First step: y1=0+0.25*1=0.25 metre. Second: y2=0.25+0.25*1=0.50 metre. Third: y3=0.50+0.25*1=0.75 metre. Fourth: y4=0.75+0.25*1=1.00 metre. This is also the exact solution y=t for this constant-slope case. The zero initial value and interval boundary t=0 provide an edge case."
}
````

## Related workflows

No source-defined multi-instrument workflow membership is recorded.

## Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

- `VERIFIED_LEDGER.json · VERIFIED_CLEAN`

- `evidence-tranche6/tranche6-results.json`