feat(solver): Phase 1 — IKCSolver C++ API and SolverRegistry #287

New Issue

forbes · 2026-02-19T21:01:29Z

forbes commented

2026-02-19 21:01:29 +00:00

Summary

Define the pluggable solver C++ API and refactor the Assembly module to call OndselSolver through it.

Scope

Per INTER_SOLVER.md Phase 1:

Core types (IKCSolver.h / Types.h)

JointTypeId, BaseJointKind enum (22 joint categories)
JointDef — solver-registered joint descriptor (DOF, params, limits, friction)
Constraint — instance with geometry refs and param values
SolveContext — full problem definition (constraints, placements, grounded set, tolerances, warm-start)
SolveResult — output (status, iterations, residual, placements, diagnostics, input hash)

IKCSolver interface

id(), name(), version() — identity
supported_joints() — joint type registry
solve(ctx) — main entry point
update(ctx, changed) — incremental (default falls back to full solve)
diagnose(ctx) — well-posedness check
is_deterministic()

SolverRegistry

scan(plugin_dir) — discover .so/.dll/.dylib plugins via kcsolve_create() / kcsolve_api_version()
register_solver() — manual registration (for built-in Ondsel)
get(), available(), get_default(), set_default()
joints_for(kind) — which solvers support a given BaseJointKind

OndselAdapter

Wraps existing OndselSolver as first IKCSolver implementation
Maps BaseJointKind to Ondsel constraint types (see joint mapping table in spec)
Translates SolveContext <-> Ondsel's Lagrangian formulation

Assembly module integration

Replace direct OndselSolver calls with SolverRegistry dispatch
No behavioral change — existing assemblies solve identically

File locations

src/Lib/KCSolve/
├── include/KCSolve/
│   ├── IKCSolver.h
│   ├── SolverRegistry.h
│   └── Types.h
├── src/
│   ├── SolverRegistry.cpp
│   └── OndselAdapter.cpp
└── CMakeLists.txt

Open questions (from spec)

Location: src/Lib/KCSolve/ (independent, server-usable) vs src/Mod/Assembly/Solver/ (simpler build)
Geometry abstraction: string refs vs TopoDS_Shape through interface
API versioning: semver strategy for plugin ABI

References

docs/INTER_SOLVER.md §4, §5, §9 Phase 1

## Summary Define the pluggable solver C++ API and refactor the Assembly module to call OndselSolver through it. ## Scope Per INTER_SOLVER.md Phase 1: ### Core types (IKCSolver.h / Types.h) - `JointTypeId`, `BaseJointKind` enum (22 joint categories) - `JointDef` — solver-registered joint descriptor (DOF, params, limits, friction) - `Constraint` — instance with geometry refs and param values - `SolveContext` — full problem definition (constraints, placements, grounded set, tolerances, warm-start) - `SolveResult` — output (status, iterations, residual, placements, diagnostics, input hash) ### IKCSolver interface - `id()`, `name()`, `version()` — identity - `supported_joints()` — joint type registry - `solve(ctx)` — main entry point - `update(ctx, changed)` — incremental (default falls back to full solve) - `diagnose(ctx)` — well-posedness check - `is_deterministic()` ### SolverRegistry - `scan(plugin_dir)` — discover .so/.dll/.dylib plugins via `kcsolve_create()` / `kcsolve_api_version()` - `register_solver()` — manual registration (for built-in Ondsel) - `get()`, `available()`, `get_default()`, `set_default()` - `joints_for(kind)` — which solvers support a given BaseJointKind ### OndselAdapter - Wraps existing OndselSolver as first IKCSolver implementation - Maps BaseJointKind to Ondsel constraint types (see joint mapping table in spec) - Translates SolveContext <-> Ondsel's Lagrangian formulation ### Assembly module integration - Replace direct OndselSolver calls with SolverRegistry dispatch - No behavioral change — existing assemblies solve identically ## File locations ``` src/Lib/KCSolve/ ├── include/KCSolve/ │ ├── IKCSolver.h │ ├── SolverRegistry.h │ └── Types.h ├── src/ │ ├── SolverRegistry.cpp │ └── OndselAdapter.cpp └── CMakeLists.txt ``` ## Open questions (from spec) 1. Location: src/Lib/KCSolve/ (independent, server-usable) vs src/Mod/Assembly/Solver/ (simpler build) 2. Geometry abstraction: string refs vs TopoDS_Shape through interface 3. API versioning: semver strategy for plugin ABI ## References - docs/INTER_SOLVER.md §4, §5, §9 Phase 1

forbes added the enhancement label 2026-02-19 21:01:29 +00:00

forbes referenced this issue

2026-02-19 21:01:43 +00:00

feat(solver): Phase 2 — pybind11 bindings and Python solver support #288

forbes referenced this issue

2026-02-19 21:01:57 +00:00

feat(solver): Phase 3 — server integration and headless solve jobs #289

forbes referenced this issue

2026-02-19 21:02:07 +00:00

feat(solver): Phase 4 — second solver plugin (API validation) #290

forbes referenced this issue

2026-02-19 21:04:12 +00:00