Roadmap for release 0.4.0

[nikoscham]

Following the release of version 0.3.0 (and the 0.3.1 patch), this roadmap outlines the vision for FEAScript 0.4.0. The primary focus of this release is scaling to larger problems: today the linear solver takes almost all of the run time, and medium-sized 2D problems already become slow. The goal for 0.4.0 is to solve noticeably larger 2D problems in a fraction of today's time, on a single thread. Version 0.4.0 also starts moving the API toward a stable 1.0.

---

Numerical Solution & Performance

• Preconditioned conjugate gradient (PCG) solver: A sparse iterative solver that becomes the default for symmetric problems (heat conduction, and later elasticity).
• Preconditioners: Jacobi, plus incomplete Cholesky (IC0) or SSOR.
• Symmetric Dirichlet conditions: Apply fixed-value conditions by eliminating their columns as well as their rows (moving the known values to the right-hand side), so the system matrix stays symmetric for PCG.
• Solver for non-symmetric problems: GMRES or BiCGStab for advection-dominated problems.
• Iterative solver robustness: A tighter default tolerance than the current Jacobi default, a clear warning or error when a solver does not converge, and regression tests that check the iterative solvers against the direct solvers.
• Assembly into typed-array CSR: Compute the sparsity pattern from the element connectivity, then assemble the system matrix directly into compressed sparse row (CSR) format with typed arrays instead of a Map per row, to cut memory use.
• Frontal solver memory: The frontal solver currently runs out of memory on medium-sized problems, because its working front is allocated with the size of the whole system. The front will be sized from the actual maximum front width (computed in a prefront pass), stored in typed arrays, and kept narrow by reordering the elements. This keeps a robust direct solver for problems where iterative solvers struggle, such as creeping flow, and a reference for checking the iterative solvers.
• Frontal solver for nonlinear general form PDEs: Use the frontal solver inside the Newton–Raphson iterations, as already done for the linear general form PDE (see the issue here).
• Jacobi stopping criterion: The Jacobi solver now stops on the relative residual ‖R − J u‖ / ‖R‖, instead of on the size of the update.
• WebGPU Jacobi stopping criterion: The WebGPU Jacobi solver ("jacobi-gpu") stops on the same relative residual as the CPU Jacobi solver (see the issue here).

API

• Solver options: solver: { method, preconditioner, tolerance } replaces setSolverMethod(). The old method keeps working, with a deprecation warning.
• Named boundary condition objects, e.g. { type: "convection", h: 1, ambientTemperature: 20 } instead of ["convection", 1, 20]. The array form keeps working, with a deprecation warning.
• Model names without the Script suffix, e.g. "heatConduction" instead of "heatConductionScript". The old names keep working, with a deprecation warning.
• Errors: Invalid input throws a FEAScriptError with an error code, instead of logging the error and continuing.
• TypeScript declarations (.d.ts) shipped in the npm package.
• Run report: result.info with whether the solver converged, the iterations, the residual and the solve time.
• A version export replacing printVersion.
• Remove the "constantTemp" boundary condition (deprecated in 0.3.0); use "constantTemperature".

Verification & Benchmarks

• Code_Aster benchmark tests for 2D heat conduction: TPLP302 (strip with a Fourier series solution) and TPLP01 (L-shaped domain with a re-entrant corner).
• Performance benchmarks in CI: Number of unknowns vs solve time and memory for every model, tracked as trends between releases and published next to the verification results (see the issue here). This is part of the wider testing and quality assurance plan proposed in #50.

Physical Modelling

• Creeping flow fix: No-slip conditions now take precedence at corners shared with a moving wall, so the lid-driven cavity is mirror-symmetric.

Please feel free to

• Propose new features or optimizations
• Express interest in contributing to any of the above tasks
• Help define priorities for the 0.4.0 release
• Share your views on the 1.0 API (model definition, boundary conditions, results)