Fiche de traçabilité de l'article Les modèles de traînée G1 à G8. Voir la méthode.
G1_RAW et G7_RAW dans BallisticsGuide/src/CompetitionBallistics.js, celles-là même que le calculateur emploie. Pics, valeurs subsoniques, largeurs de pic : tout est recalculé sur elles.La page écrivait : « La forme de référence G7, plus profilée, a un pic transsonique plus bas et plus plat que le G1 : c'est la raison physique pour laquelle un CB exprimé en G7 reste quasi constant ».
« Plus bas » est vrai. « Plus plat » est faux, et les tables du site le disent :
| G1 | G7 | |
|---|---|---|
| C_d subsonique | 0,205 | 0,119 |
| Pic | 0,499 à Mach 1,10 | 0,402 à Mach 1,02 |
| Amplification pic / subsonique | × 2,43 | × 3,36 |
| Largeur à 80 % du pic | 0,50 Mach | 0,20 Mach |
Le pic du G7 est donc deux fois et demie plus étroit que celui du G1, et son amplification est plus forte. La page affirmait le contraire de ce que contiennent les tables qu'elle décrit.
Et la page se contredisait elle-même. Deux sections plus bas, un encadré donne la bonne explication : « ce qui rend le G7 pertinent n'est pas une identité de profil, mais le fait que sa courbe de traînée suive de près celle d'une balle élancée — d'où un facteur de forme quasi constant ».
C'est exact, et c'est tout autre chose. Ce qui rend un CB G7 stable est la ressemblance entre la courbe de la référence et celle de la balle : c'est le rapport des deux traînées qui reste constant, pas la traînée de la référence. La platitude du pic n'y est pour rien.
L'erreur remplaçait donc une explication juste, déjà présente, par une fausse plus intuitive. La page porte désormais la mesure et renvoie à son propre encadré.
Le tableau de l'article décrit le G5 comme une ogive tangente de 6,19 calibres à boat-tail court de 7,5°. Le schéma des silhouettes l'étiquetait « ogive sécante ».
Le tableau a raison : le G5 est bien à ogive tangente, et c'est le G6 qui est sécant à culot plat. Confirmé sur source extérieure. L'étiquette fautive effaçait au passage ce qui distingue précisément ces deux références l'une de l'autre — et la faisait apparaître deux fois, en commentaire et en texte visible.
Réserve consignée dans le fichier même, pour qui le reprendrait : les silhouettes n'encodent pas la distinction tangente/sécante — toutes les ogives y sont un simple Bézier quadratique. Seules les étiquettes portent cette information. Il ne faut donc pas « corriger » les formes d'après elles.
Elle se présentait comme une « allure qualitative », ce qui abaisse la barre — mais pas au point d'autoriser ceci :
Elle a été régénérée depuis les tables BRL du site, points par points. Ce n'est plus un croquis mais un tracé, et la légende y porte les deux pics chiffrés.
Une leçon de méthode, payée une deuxième fois dans la même journée. Ma première régénération appliquait .replace('.', ',') — pour la virgule décimale française — à toute la balise SVG et non au seul nombre. Les coordonnées devenaient y="123,4", invalides ; les étiquettes d'axe s'affichaient toutes « 0 ».
Le fichier était XML valide. Le contrôle qui l'a attrapé est la conversion en image et le coup d'œil. Un contrôle automatique a été ajouté à la génération : aucun attribut numérique ne doit contenir de virgule.
dragCoefficient(model, mach, spline = true) — l'interpolation par spline est bien le défaut, et calculateur-balistique.php charge bien cette bibliothèque.