The C++ rewrite follows the same physical algorithm but is structured for production robustness. The solver engine manages inlet/fluid initialization, geometry ingestion from host-platform objects, QO-line and streamline setup, the main iterative solve loop (flow population, velocity marching, mass-flow balancing, streamline repositioning, convergence checks), and post-processing for blade-loading output.

A critical bug found by examining the original Fortran code was that the hub-velocity prediction — an iterative sub-process that finds the hub velocity giving the correct mass-flow rate at each QO line — had been overlooked and treated as a single-step computation. Implementing the full iterative predictor (derived from a Fortran subroutine in the original code) resolved the convergence issues that plagued the Python prototype.

Instead of the polynomial-regression workaround from Python, the C++ solver extracts blade-angle and thickness surfaces directly from the host platform's blade-row objects. For any $(z, r)$ query, a line parallel to the axis intersects the surface to yield the required angle value; surface iso-curve tangents give the partial derivatives via linear algebra.

Direct surface intersection was accurate but slow. A 1D cubic-spline interpolation strategy exploits the fact that QO lines are fixed: before the main loop, blade data is sampled along each QO line and approximated with cubic splines. Inside the solve loop, fast 1D lookups replace expensive 3D surface intersections — dramatically reducing per-iteration cost.

The solver maintains ~50 flow variables (pressure, temperature, density, velocity components, blade angles, curvature, etc.) at every grid point — each streamline × QO-line intersection. Originally stored as a 2D array of structs (AOS), field access required two pointer indirections: outer vector → inner vector → struct → field.

Switching to a structure-of-arrays layout — where each variable is stored in a contiguous 1D std::vector indexed by row * cols + col — dramatically improved performance. Access becomes struct → vector → data, and sequential sweeps over a single variable (the dominant pattern in the solver loop) hit L1/L2 cache almost every time.

The SOA container uses C++ template metaprogramming with tag-dispatched type descriptors: each flow variable is a unique type, and compile-time index resolution via std::tuple and fold expressions eliminates all runtime lookup overhead. Direct data pointers are also exposed for potential SIMD use.

This single change — AOS → SOA — brought the solver to sub-second total solve time for dozens of iterations on typical machine geometries (10–20 streamlines × 10–30 QO lines).

With the sequential solver already running under a second, OpenMP parallel directives were tested to see if further speedup was possible. The result was slower execution — the thread-creation and synchronization overhead from #pragma omp parallel exceeded the computation time of each loop body.

The grid sizes in typical preliminary design (hundreds to low thousands of points) are simply too small for the parallelization to amortize the fixed cost of thread management. The lesson: for small, cache-friendly workloads, a tight sequential loop with good data locality beats multi-threading.

OpenMP remains available as a build option for unusually large meshes, but the default path stays single-threaded.

The solver is exposed through a dedicated Qt task window with three visualization panels:

• Streamline geometry plot: displays the converged streamlines and QO lines forming the computational grid.
• QO-line data plot: shows any selected thermodynamic variable along a chosen QO line (hub → shroud).
• 2D contour plot: a VTK-rendered colour-mapped visualization of any flow variable across the entire meridional plane, using Delaunay triangulation of the grid points.

Additional controls let the user select which stage and segment to analyze, configure solver parameters (iteration limits, relaxation, tolerances), choose between interpolation or direct blade-data evaluation, and select the inlet-condition side.

The solver was cross-compared against the existing hub-to-shroud (H2S) solver and full CFD results across multiple test cases. When accuracy was deemed acceptable for the massive time advantage it provides (sub-second vs. minutes), it was merged as a beta feature.

Comprehensive documentation was prepared alongside the submission to the central repository, covering the algorithm theory, API usage, solver settings, and limitations.