Documentation
Library manual
Reference for the self-contained C++20 divisible-load scheduling library that powers this portal: what it is for, what it covers, how to build and use it, and how it is licensed. Concepts and notation are defined in the Knowledge base. This manual is a living document and will grow as new problem classes and solvers are added.
Architecture
The C++20 core is built around three types. DLSInstance is the problem: a total load V, a list of Processor structs (each carrying S, C, A, B, optional per-unit cost coefficients, optional convex piecewise computation-time pieces, and the four-state energy model fields), an optional result-return fraction β, and originator power rates for the master node. DLSSolution is the result: a solve status, the makespan Cmax, total energy E, total cost G, the activation sequence, and a list of LoadFragment records each carrying the processor index, the assigned load, and the full Gantt timing (commStart, commFinish, computeStart, computeFinish). DLSSolver is the interface every algorithm implements: a single solve(DLSInstance&, SolverConfig&) → DLSSolution method plus name() and category() (Exact or Heuristic).
The solver registry ties the portfolio together. availableSolvers() returns the stable names of every method compiled into the current build. makeSolver(name, SolverOptions) constructs the solver; SolverOptions is a flat struct carrying every algorithm-specific parameter (populationSize, maxGenerations, epsilon, deadline, nodeBudget, evaluatorBackend, …). Each factory reads the fields that apply to it and ignores the rest, keeping the interface uniform across all twelve solvers.
The LP and MILP back-ends live behind an abstract ScheduleEvaluator interface so they are hot-swappable. The default back-end is an in-house simplex written entirely within the library (no external headers, no linking step beyond the standard library), which makes the dependency-free build fully portable. When HiGHS is available (-DDLS_WITH_HIGHS=ON), a thin HiGHSScheduleEvaluator adapter replaces the simplex for the LP-intensive solvers (branch-and-bound, dual bisection) and enables the two MILP solvers (exact-milp, milp-multi). All JSON output is produced by a minimal hand-written emitter in core/json_io.hpp that also avoids any third-party dependency.
A thin C-ABI bridge (libdls_c.so) exposes the core to any language. Each function (dls_solve, dls_pareto, dls_map, dls_bench, dls_topology) accepts UTF-8 encoded strings (an instance text and an options key=value list) and returns a char* owning a JSON result; the caller frees it with dls_free. The bundled frontend/dls/__init__.py loads this library via Python ctypes with no compiled extension, no pip install, and no pybind11. On top of that, the FastAPI layer in frontend/api/main.py wraps the Python module into six JSON endpoints and serves the built SvelteKit SPA. The dependency chain is strictly one-way: front-end → Python binding → C-ABI → C++ core. The C++ core is completely unaware of the web layer.