Correction de la Stabilité Numérique N-Body¶

Description du Problème¶

Une instabilité numérique a été observée dans la simulation N-body, entraînant une dérive d'énergie, des trajectoires erratiques et occasionnellement des valeurs NaN. Ces problèmes étaient particulièrement graves dans les builds release et lors des opérations d'inversion temporelle.

Causes Techniques¶

1. Perte de Précision des Nombres Flottants¶

Les simulations physiques impliquant des calculs cumulatifs sont très sensibles aux erreurs d'arrondi. L'utilisation de la précision float (32-bit) entraînait une dérive d'énergie importante sur de longues périodes, car de petites erreurs dans les calculs de force s'accumulaient à chaque image.

2. Bug de Damping en Inversion Temporelle¶

Le mécanisme d'amortissement radial (zone de confinement) utilisait directement delta_time. Lorsque le temps était inversé (delta_time < 0), le terme d'amortissement devenait une force d'accélération, provoquant une explosion d'énergie des corps qui étaient alors éjectés du volume de simulation.

3. Effets Secondaires du Fast-Math¶

Les optimisations agressives du compilateur (-ffast-math) sacrifient la conformité IEEE 754 pour la vitesse. Cela peut briser les propriétés symplectiques de l'intégrateur Velocity Verlet, entraînant des comportements non physiques.

Solution¶

1. Passage en Double Précision¶

L'état de la physique et les calculs ont été migrés vers la précision double (64-bit). - Champs affectés : Position, vitesse, masse et calculs d'énergie. - Rendu : Le GPU reçoit toujours des données float via les VBO pour la performance, mais la "source de vérité" de la simulation est désormais en haute précision.

2. Amortissement Symétrique¶

La logique d'amortissement a été mise à jour pour utiliser fabs(delta_time), garantissant qu'elle reste dissipative quelle que soit la direction du temps :

float damping_factor = 1.0F - (sim->damping * fabsf(delta_time));

3. Gestion des Flags au Niveau du Build¶

Au lieu de pragmas dans le code source, nous imposons désormais un comportement flottant standard via CMakeLists.txt sur les fichiers critiques :

set_source_files_properties(
    src/nbody/nbody_physics.c
    src/nbody/nbody_diagnostics.c
    src/nbody/nbody_preset.c
    PROPERTIES COMPILE_FLAGS "-fno-fast-math"
)

Cela garantit que le cœur de la physique est toujours compilé avec une conformité IEEE 754 stricte, même si le reste de l'application utilise des optimisations agressives.

Vérification¶

Des tests de longue durée (1200s) confirment une dérive d'énergie inférieure à 6%, et les tests d'inversion temporelle montrent une réversibilité quasi parfaite (erreur de \(10^{-11}\)), confirmant la robustesse de la nouvelle implémentation.

Seuil de dérive d'énergie (6%)¶

Le test de longue durée test_nbody_stability simule 1200 secondes et mesure la dérive relative d'énergie \(|E - E_0| / |E_0|\). La dérive mesurée se stabilise de manière reproductible à ~5.64% sur toutes les plateformes (Linux, Wine/Windows).

Cette dérive n'est pas une erreur de précision — c'est le résultat attendu de l'amortissement radial de confinement qui dissipe intentionnellement l'énergie cinétique radiale lorsque les corps franchissent le rayon de confinement. L'amortissement préserve le moment angulaire (seule la composante radiale de la vitesse est amortie) et conserve la quantité de mouvement linéaire (impulsion transférée à l'étoile centrale).

Le seuil du test est fixé à 6% (précédemment 5%), offrant ~7% de marge au-dessus du plateau mesuré. C'est suffisamment serré pour détecter de vraies régressions tout en accommodant la dissipation d'énergie par conception.

dvec3.h — Helpers Vectoriels en Double Précision¶

Ajouté le : 2026-05-08

Pourquoi pas cglm ?¶

cglm (v0.9.x) est la bibliothèque mathématique du projet pour le rendu OpenGL. Cependant, elle ne fournit que des types en précision float (vec3, vec4, mat4). Il n'existe pas de type dvec3 ni d'option de build CGLM_DOUBLE — contrairement à la bibliothèque C++ GLM qui propose glm::dvec3.

Est-ce que cglm optimise vec3 ?¶

Non. Les intrinsics SIMD (SSE/NEON) dans cglm ne sont utilisés que pour les types dont la largeur correspond aux registres matériels :

Type	Intrinsics SIMD	Raison
`vec4`	54	4 floats = 1 registre SSE `__m128`
`mat4`	12	4×4 colonnes, opérations 4-wide
`vec3`	0	3 composantes ne remplissent pas proprement un lane 128-bit

Chaque fonction glm_vec3_* (add, sub, dot, copy, scale, …) est une simple boucle scalaire :

// cglm/vec3.h — implémentation réelle
glm_vec3_add(vec3 a, vec3 b, vec3 dest) {
    dest[0] = a[0] + b[0];
    dest[1] = a[1] + b[1];
    dest[2] = a[2] + b[2];
}

Décision de conception¶

Puisque glm_vec3_* est du pur wrapping scalaire sans aucun bénéfice SIMD, migrer la simulation n-body de float/vec3 vers double[3] avec accès composante par composante ne cause aucune régression de performance.

Pour garder le code lisible et éviter le boilerplate répétitif [0]/[1]/[2], nous introduisons include/dvec3.h — une bibliothèque header-only minimale qui reflète l'API vec3 de cglm pour les tableaux double :

Fonction dvec3	Équivalent cglm	Description
`dvec3_copy`	`glm_vec3_copy`	Copie 3 composantes
`dvec3_add`	`glm_vec3_add`	`dest = a + b`
`dvec3_sub`	`glm_vec3_sub`	`dest = a - b`
`dvec3_scale`	`glm_vec3_scale`	`dest = v × s`
`dvec3_dot`	`glm_vec3_dot`	Produit scalaire
`dvec3_norm`	`glm_vec3_norm`	Longueur
`dvec3_normalize`	`glm_vec3_normalize`	Normalisation en place
`dvec3_muladds`	—	`dest += v × s` (Verlet)
`dvec3_addto`	—	`dest += v` (accumulation)
`dvec3_subfrom`	—	`dest -= v`
`dvec3_zero`	`glm_vec3_zero`	Mettre à `{0, 0, 0}`

Toutes les fonctions sont static inline — zéro surcoût d'appel, code généré identique à la version manuelle.

Considérations futures¶

Montée en charge : Avec 14 corps, le scalaire double est négligeable. Si le nombre croît vers les centaines, envisager du SIMD AVX __m256d (4-wide double).
Évolution de cglm : Si cglm ajoute le support dvec3 dans une version future, ces helpers pourront être remplacés de manière transparente.