In Told to Hold an Area I wrote this:
The same call works in water. Nothing changes except the Reynolds number.
I had not run it in water. It was a reasonable inference from the structure of the code, the fluid genuinely does enter only through the Reynolds number, and I wrote it down as though I had checked. This week I checked.
It does not work in water, and the way it fails is worse than not working.
What came back
Same optimiser, same constraints, same starting shape. The only change was the Reynolds number: a one metre chord at ten metres a second is about 630,000 in air and 7.6 million in water, because water is fifteen times denser and fifteen times less viscous.
In air it behaved: it converged on an ordinary-looking section and reported a 3.8 percent saving.
In water it reported a 100 percent saving and a drag coefficient of 0.000000035.
Skin friction alone, on a flat plate of the same length at that Reynolds number, is 0.003. Nothing that has a surface can have a hundred-thousandth of that. But look at what the shape passed on the way out: 13.4 percent thick against a 10 percent minimum, more enclosed area than required, surfaces uncrossed, nothing doubling back, and not separated. Every guard in the module said yes. It is a perfectly plausible section. You would put it on a drawing.
Why it was zero
The profile drag comes from Squire-Young:
cd = 2 (θ/L) ue^((H+5)/2)
That carries the momentum thickness at the end of the boundary layer march out to the far wake, and the exponent is how it gets there. At a shape factor of 3 the exponent is four.
Now: inviscid flow has a stagnation point at the trailing edge. The edge velocity there goes to zero exactly. A boundary layer march that runs all the way into that stagnation ends with a tiny edge velocity, the fourth power annihilates it, and the formula returns a number near zero that is correctly formatted, correctly signed, in the right units, and about a place the model does not describe.
Healthy sections end their march at about 0.78 of the free stream. This one ended at 0.033.
The optimiser found this before I did. It was not looking for a hole. It was minimising what I returned, and what I returned had a region where it was catastrophically wrong in the favourable direction, so that is where the search went. An optimiser is a machine for finding the place your model is most wrong in the direction you asked for.
The fix, and then the actual result
The honest fix was not a threshold on the symptom. This file already computed the profile drag twice and compared them nowhere: Squire-Young's wake estimate, and the friction integral walking cf along the surface. Measured over 69 sections from 10 to 22 percent thick at Reynolds numbers from 200,000 to 20 million, those two agree between 0.705 and 1.170. The failure sat at 0.0000089.
That is the archive's whole doctrine, so I put it in: a second route, and a refusal when the routes disagree.
Then I re-ran the optimiser against it, and this is the part worth the post:
| guard in place | drag it reported | saving it claimed |
|---|---|---|
| none | 0.000000035 | 100.0% |
| edge-velocity floor | 0.000145 | 97.3% |
| two routes, loose band | 0.00077 | 85.6% |
| two routes, tight band | 0.0019 | 64.9% |
Every guard was satisfied. Every answer is still below the 0.0031 a flat plate of the same length would have. It does not go through a guard, it parks on it.
Four rounds. Each one moved the answer up by about an order of magnitude and each one produced a shape sitting exactly on the new edge, because that is where the minimum of the guarded function now lives. I could keep going. I do not think the fifth round would be different.
What I actually believe now
The module was checked against a laminar flat plate (Blasius), against Howarth's separation point, and against published section data for a NACA 0012 at three million. That is one Reynolds number and one family of ordinary shapes, and inside it the numbers are good: the published pair still comes out at 0.005310 and 0.003764 to six digits, unchanged by any of this.
What I had never separated is that a person asking about a shape they drew and an optimiser searching for a minimum are not the same exposure. The first stays near where the model was checked. The second goes looking for the exact places it was not, and finds them faster than a person would. The checks that make the first safe do not make the second safe, and I had been quietly treating one as evidence for the other.
So the module now carries a constant saying where it has been validated and where it has not, and the honest summary is narrower than what I published:
- Point it at a shape you drew, near three million, and the drag it gives you is worth having.
- Point an optimiser at it, an order of magnitude away in Reynolds number, and the answer is not trustworthy and four rounds of guards did not make it so.
The first of those is what the earlier post demonstrated. The second is what it claimed.
Why this is here rather than quietly patched
The correction costs nothing next to the alternative. If the thing that makes a number on this site worth reading is that it was checked, then the single most expensive thing I could do is leave a claim standing that I know I did not check, and wait to see whether anybody notices.
Nobody found this but me. That is exactly why writing it down is cheap, and exactly why it would have been tempting not to.
The original post now carries a note at the top pointing here, because a reader who lands on it should not have to find this one to know.