Vérification — Le solveur balistique 3-DOF

Fiche de traçabilité de BallisticsGuide/src/CompetitionBallistics.js (943 lignes), le solveur qui alimente le calculateur balistique et les outils de balistique. Voir la méthode.

Pourquoi ce code passe avant le reste. Il ne s'agit pas d'une page de plus : c'est l'arbitre. Plusieurs fiches de cette passe — tir en pente, mesure d'un groupement, le dossier balistique intérieure — appuient leurs conclusions sur ses sorties. Un solveur faux ferait certifier des erreurs par des fiches qui se croient rigoureuses. Il était donc contrôlé partout, et vérifié nulle part.

Le solveur est un point-masse à 3 degrés de liberté. Le passage à 6-DOF, dont le code Julia existe, est un chantier distinct ; cette fiche porte sur la version en service.

Cinq contrôles indépendants, choisis pour ne pas dépendre les uns des autres :

• intégration de référence réécrite d'après le manuel, avec la même table de traînée, pour confronter les deux résultats ;
• boucle fermée sur le coefficient balistique : injecter un CB, produire une trajectoire, en réextraire le CB ;
• cas analytiques : atmosphère normalisée, densité, vitesse du son, pression barométrique ;
• convergence sur le pas d'intégration, puis distinction entre erreur d'intégration et artefact d'échantillonnage ;
• grandeurs dérivées confrontées aux pages du wiki qui les publient.

bcFromTwoChronographs() déduit un coefficient balistique de deux vitesses mesurées à deux distances. Elle est exposée aux utilisateurs par la page d'outils.

Elle appliquait la relation

$$\frac{1}{v_2} - \frac{1}{v_1} = k,t$$

qui est l'intégration de la traînée en $v^2$ contre le temps — en lui passant une distance. Or contre la distance, la relation est logarithmique :

$$\ln\frac{v_1}{v_2} = k,x$$

Le résultat était faux de cinq ordres de grandeur. Boucle fermée sur trois valeurs, avant correction :

Après correction — forme logarithmique, constante d'unités explicitée, et suppression d'une renormalisation par $\rho_0$ qui n'avait pas lieu d'être puisque la densité de la mesure est déjà dans le calcul :

Le résidu est celui qu'on attend d'une méthode qui prend le $C_d$ à la vitesse moyenne de l'intervalle : il décroît quand la perte de vitesse diminue.

Le texte de l'outil a suivi : il annonçait une valeur « ramenée aux conditions standards ICAO », ce qui n'est plus — ni nécessaire.

La chaîne de traînée porte un * (4.0 / Math.PI) qui multiplie l'aire frontale $\pi d^2/4$ pour rendre $d^2$. Au premier regard, c'est 27 % de traînée en trop, les tables BRL référençant bien $C_d$ à l'aire frontale.

C'est pourtant correct, et le test l'établit sans ambiguïté. La densité sectionnelle du monde du tir se définit sur $d^2$, non sur l'aire frontale — $SD = m/d^2$, en lb/in². Comme le facteur de forme vaut $i = SD/CB$, la surface qui doit apparaître dans l'équation de traînée est celle qui a servi à définir $SD$, soit $d^2$. Le 4/π réalise exactement cet appariement.

L'intégration écrite d'après la formule naïve — celle qui garde $\pi d^2/4$ — donne une .308 de 175 gr, $G7 = 0{,}243$, arrivant à 1000 yards à 1 462 fps au lieu de 1 153. Une .308 transsonique à cette distance ne vole pas à 1 462 fps ; c'est la version « naïve » qui est fausse.

Le code ne portait aucun commentaire sur ce point. Il en porte un désormais, avec le contre-exemple chiffré — cette ligne est un piège pour quiconque voudra « simplifier ».

Les points de report ne sont pas interpolés. Le solveur retourne les pas d'intégration bruts ; trajectoryTable() prend le premier pas atteignant la distance voulue, sans interpoler entre les deux qui l'encadrent. À 800 m/s et $dt = 5\times10^{-4}$, cela fait jusqu'à 40 cm d'erreur de distance, soit quelques millimètres de chute à 500 m. Négligeable pour le tireur, mais c'est cela — et non l'erreur d'intégration — qu'on mesure en croyant tester la convergence : le déficit de distance suit exactement le pas.

Le solveur s'arrête à la distance demandée, sans le signaler. Interroger la trajectoire au-delà rend silencieusement le dernier point calculé. Ce n'est pas un défaut du code — mais tout banc de test doit vérifier que le point obtenu atteint bien la distance visée, faute de quoi il compare des trajectoires tronquées en croyant faire varier un paramètre. C'est arrivé pendant cet audit, et cela a d'abord ressemblé à un bug du solveur.

• La dérive gyroscopique n'est pas reproductible à partir des données publiées : le portail annonce « ≈ 31 cm à 1 000 m » pour une .308 en 1:10 sans préciser la balle ni la vitesse. Le solveur donne 29 à 43 cm selon le projectile — et 31 cm correspond bien mieux à 1 000 yards qu'à 1 000 mètres. La formule empirique de Litz n'a pas pu être confrontée à sa source, et la vignette n'a pas été corrigée faute de savoir laquelle des deux valeurs elle visait.
• Les tables de traînée BRL ont été contrôlées sur six points de repère par modèle, pas dépouillées intégralement. Les valeurs vues sont les valeurs canoniques.
• Le saut aérodynamique et la dérive gyroscopique sont ajoutés a posteriori, hors intégration. C'est la limite structurelle d'un point-masse, assumée par le code ; elle disparaîtra avec le passage au 6-DOF.
• Aucune confrontation à un solveur tiers n'a été faite. Le manuel du site invoque JBM comme référence de validation ; cette validation-là n'a pas été rejouée ici.