Authors:Denis Gueyffier (Direction Scientifique Générale, ONERA, Institut Polytechnique de Paris, Palaiseau, France)

View PDF HTML (experimental)

Abstract:The drag and mobility of bodies in viscous (Stokes) flow govern problems in shape design, suspensions, or microorganism swimming. Classical solvers compute them accurately but expensively; purely learned surrogates are fast but unreliable off their training data. We combine both: a solver's exactness for the part of the solution operator known in closed form, and learning for the part that is not. For incompressible Stokes flow the elliptic-core kernel is already known: in free space the Leray projector is a single rotation-equivariant Stokeslet with no free parameters, and the boundary-integral solver built on it is exact to machine precision at $O(N)$. The one object with no closed form is the boundary correction. We split the operator: fix the core exactly and equivariantly, and learn only that correction, as a well-conditioned second-kind operator. On a Stokes testbed where the exact solve is ground truth, the split gives a working solver ($2 \times 10^{-3}$ end-to-end, $5$-$16\times$ more data-efficient than a black-box DeepONet) and overturns three expectations. (i) Conditioning is not the bottleneck: a $10^{16}$-conditioned first-kind and a bounded second-kind operator give the same error. (ii) Cross-shape generalization is governed by the descriptor's equivariance, not capacity: a noninvariant descriptor degrades by $>10^5\times$ under rotation, while canonicalization restores near-machine transfer. (iii) Coverage, not expressivity, is the lever; a local equivariant kernel removes the heavy out-of-distribution tail, cutting worst-case interior error from $O(10)$ to $\sim 10^{-7}$. We then open the central exterior problem in 3D: a completed double layer, made exact by quadrature by expansion, is second-kind well-conditioned and $SO(3)$-equivariant, reproduces the analytic drag of spheres and ellipsoids, and composes across bodies.

Submission history

From: Denis Gueyffier [view email]
[v1] Tue, 23 Jun 2026 18:32:42 UTC (118 KB)