Follow-up from the mesh.relax() work.
In 2D, relaxation buys a real accuracy win (13% lower fault-localised P1 interpolation error applied per generation, 7% at the end). In 3D the same operation improves mesh quality substantially but leaves accuracy unchanged:
|
q med |
q p10 |
q<0.1 |
p99 dihedral |
interp error |
| after adapt |
0.325 |
0.146 |
3.56% |
153.5 deg |
— |
| after relax |
0.386 |
0.178 |
1.75% |
145.7 deg |
+0.5% |
The near-degenerate population halves and the worst-angle tail pulls back 8 degrees, but the interpolation error of an isotropic feature does not move.
Hypothesis. This is consistent rather than contradictory. Relaxation holds the size distribution by construction, so its only route to lower error is by aligning cells with the feature — which is exactly what the 2D pictures show (cells rotating onto the fault). The 3D test used an isotropic metric around a cylindrical band, which gives the mover no reason to align anything. Quality improves (the shape term working) while error does not (nothing asked for alignment).
Test. Repeat the 3D measurement with an anisotropic (tensor) metric — small across the feature, base along it, as _mmpde_mover already supports — and see whether the 2D-style error gain appears. If it does, 3D relaxation is worth enabling for accuracy and the docs should say so; if it does not, the current "quality only, not accuracy" guidance stands.
Ruled out already:
- Base provenance. Relaxation repairs the PETSc uniform 1:8 split damage well (q p10 0.449 -> 0.526 on a uniformly split base), so the fixed reference-octahedron diagonal is not the limiter.
- Stuck mover. max|dx| ~5e-2 against h ~1e-2; it moves plenty, and 30 vs 120 iterations give the same answer.
Docs currently state the conservative reading in docs/developer/subsystems/mesh-shape-relaxation.md and in the Mesh.relax docstring.
Follow-up from the
mesh.relax()work.In 2D, relaxation buys a real accuracy win (13% lower fault-localised P1 interpolation error applied per generation, 7% at the end). In 3D the same operation improves mesh quality substantially but leaves accuracy unchanged:
The near-degenerate population halves and the worst-angle tail pulls back 8 degrees, but the interpolation error of an isotropic feature does not move.
Hypothesis. This is consistent rather than contradictory. Relaxation holds the size distribution by construction, so its only route to lower error is by aligning cells with the feature — which is exactly what the 2D pictures show (cells rotating onto the fault). The 3D test used an isotropic metric around a cylindrical band, which gives the mover no reason to align anything. Quality improves (the shape term working) while error does not (nothing asked for alignment).
Test. Repeat the 3D measurement with an anisotropic (tensor) metric — small across the feature, base along it, as
_mmpde_moveralready supports — and see whether the 2D-style error gain appears. If it does, 3D relaxation is worth enabling for accuracy and the docs should say so; if it does not, the current "quality only, not accuracy" guidance stands.Ruled out already:
Docs currently state the conservative reading in
docs/developer/subsystems/mesh-shape-relaxation.mdand in theMesh.relaxdocstring.