Vous devez savoir deux choses différentes sur une simulation : si le code résout correctement les équations et si le modèle est suffisamment précis pour le problème du monde réel. La première question est la vérification. La deuxième question est la validation.
Mais cela ne suffit pas. Vous devez également comprendre à quel point vous pouvez faire confiance aux chiffres que votre simulation produit. C’est là que la quantification de l’incertitude entre dans le flux de travail.
Ce guide explique le cadre VVUQ complet : vérification, validation et quantification de l’incertitude. Il comprend également des exemples pratiques Python et Fipy qui peuvent vous aider à appliquer ces idées dans votre propre travail de simulation.
Points à retenir clés
- La vérification répond à la question : avons-nous résolu les équations, n’est-ce pas ? Il vérifie l’exactitude du code, la précision numérique et les bogues de mise en œuvre.
- La validation répond à la question : avons-nous résolu les bonnes équations ? Il compare la sortie de simulation avec des données expérimentales, des données de référence ou des résultats de référence fiables.
- La quantification de l’incertitude répond à la question : dans quelle mesure pouvons-nous faire confiance à ces résultats ? Il propage les incertitudes d’entrée à travers le modèle et signale des limites de confiance sur les prédictions.
- UQ est souvent mentionné dans les discussions V&v mais rarement mis en œuvre avec des exemples python pratiques. Ce guide donne des points de départ concrets.
- Le portefeuille de normes ASME VVUQ fournit une structure largement adoptée pour les flux de travail VVUQ dans les disciplines de calcul.
Vérification, validation et quantification de l’incertitude : pourquoi ils appartiennent ensemble
Si vous avez déjà exécuté une simulation et demandé si vous pouviez faire confiance aux résultats, vous avez déjà rencontré le problème auquel VVUQ répond.
La vérification, la validation et la quantification de l’incertitude ne sont pas des tâches distinctes que vous effectuez de manière indépendante. Ils forment un pipeline de crédibilité :
- La vérification prouve que le code est mathématiquement et informatiquement correct.
- La validation vérifie si le modèle représente suffisamment le système réel pour l’utilisation prévue.
- La quantification de l’incertitude vous indique à quel point vous pouvez être confiant dans les prévisions.
Le framework ASME VVUQ formalise ce pipeline dans un flux de travail structuré utilisé dans les domaines de la mécanique des solides informatiques, de la dynamique des fluides, des dispositifs médicaux et d’autres domaines de la simulation. asme vvuq
La distinction entre vérification et validation est souvent résumée par deux questions.
| Question | Ce que cela veut dire | Ce que vous vérifiez |
|---|---|---|
| Résolvons-nous les équations, n’est-ce pas ? | Vérification | Bogues de codage, erreurs numériques et erreurs de discrétisation |
| Résolvons-nous les bonnes équations ? | Validation | Précision du modèle physique, conditions aux limites et hypothèses |
La troisième question est : Dans quelle mesure pouvons-nous être confiants ? C’est là que la quantification de l’incertitude entre dans le processus.
Une simulation peut être vérifiée et validée, tout en produisant des prédictions avec de larges intervalles d’incertitude. Si ces intervalles sont trop larges, le résultat peut ne pas être utile pour la conception, la réglementation ou la prise de décision.
1. Vérification : prouver que votre code est correct
La vérification est mathématique et informatique. Il ne teste pas directement le monde réel. Au lieu de cela, il suppose que les équations gouvernantes sont correctes et demande si le programme informatique les résout sans erreurs numériques ou de mise en œuvre.
La vérification comporte deux aspects principaux : la vérification du code et l’ordre des tests de précision.
Vérification du code : l’implémentation correspond-elle aux calculs ?
La vérification du code démontre que le solveur implémente correctement le modèle mathématique. Deux méthodes largement utilisées sont la méthode des solutions fabriquées et l’ordre des tests de précision.
Méthode des solutions fabriquées
La méthode des solutions manufacturées est l’un des outils les plus solides pour la vérification des codes en sciences informatiques. Cela fonctionne en créant une solution analytique connue, en calculant le terme source requis, puis en vérifiant si le code reproduit cette solution.
La procédure est :
- Choisissez une solution analytique fluide, telle que
u_m = sin(x) * cos(y) * exp(-t). - Remplacez la solution fabriquée dans l’opérateur PDE pour calculer le terme de source requis.
- Exécutez la simulation avec le terme de la source manufacturée et les limites ou les conditions initiales correspondantes.
- Comparez la solution numérique à la solution de fabrication exacte.
- Exécutez des études de raffinement de maillage pour vérifier que l’ordre de convergence observé correspond à l’ordre théorique.
Voici un exemple de style fipy simplifié pour un problème de diffusion transitoire :
import numpy as np
from fipy import Grid2D, CellVariable, TransientTerm, DiffusionTerm
# Manufactured solution:
# u(x, y, t) = sin(pi*x) * sin(pi*y) * exp(-2*pi^2*t)
nx, ny = 32, 32
Lx, Ly = 1.0, 1.0
dx = Lx / nx
dy = Ly / ny
mesh = Grid2D(nx=nx, ny=ny, dx=dx, dy=dy)
x, y = mesh.cellCenters
u = CellVariable(name="u", mesh=mesh, hasOld=True)
def exact_solution(t):
return np.sin(np.pi * x) * np.sin(np.pi * y) * np.exp(-2 * np.pi**2 * t)
# Initial condition
u.setValue(exact_solution(0.0))
# For this manufactured solution and diffusion coefficient 1:
# du/dt = Laplacian(u), so the source term is zero.
source = CellVariable(name="source", mesh=mesh, value=0.0)
eq = TransientTerm(var=u) == DiffusionTerm(coeff=1.0, var=u) + source
dt = 0.001
nt = 100
for step in range(nt):
u.updateOld()
eq.solve(var=u, dt=dt)
t_final = dt * nt
exact = exact_solution(t_final)
l2_error = np.sqrt(np.mean((u.value - exact) ** 2))
print(f"L2 error at t={t_final:.3f}: {l2_error:.6e}")
Si vous divisez par deux la taille du maillage et que l’erreur baisse d’environ quatre, un schéma de second ordre se comporte comme prévu. Si ce n’est pas le cas, la mise en œuvre peut contenir un bogue ou le traitement des limites peut réduire l’ordre observé.
Ordre de test de précision
Ordre de précision Les tests vérifient que le code atteint le taux de convergence attendu dans le cadre du raffinement du maillage.
Pour un schéma de volume fini de second ordre, la réduction de moitié de l’espacement du maillage devrait réduire l’erreur d’environ un facteur de quatre.
La procédure est :
- Choisissez un problème avec une solution exacte connue, à partir de MMS ou d’un benchmark.
- Résolvez le problème sur une séquence de maillages raffinés, tels que 32 × 32, 64 × 64 et 128 × 128.
- Calculez une norme d’erreur à chaque niveau de raffinement, comme L1, L2 ou L∞.
- Erreur de tracé en fonction de la taille du maillage sur un tracé journal.
- Calculez l’ordre observé avec
order = log(e_coarse / e_fine) / log(h_coarse / h_fine). - Vérifiez que l’ordre observé correspond à l’ordre de discrétisation théorique dans une tolérance raisonnable.
Il s’agit d’une exigence minimale pour tout code PDE qui revendique l’exactitude numérique. Sans cela, les estimations d’erreurs et les conclusions de maillage-convergence sont faibles.
Avertissement important concernant la comparaison de codes croisés
La comparaison de deux codes différents peut s’avérer utile en tant que contrôle de santé mentale, mais cela ne remplace pas la vérification par rapport aux solutions analytiques ou fabriquées.
Deux codes peuvent convenir et sont toujours erronés si les deux partagent la même erreur systématique. La comparaison de codes croisés doit être utilisée comme vérification supplémentaire après un MMS ou un test de commande.
2. Validation : comparaison des simulations à la réalité
La validation évalue si le modèle de simulation est suffisamment précis pour son utilisation prévue. Pour ce faire, il compare les prédictions avec des données expérimentales indépendantes, des données de référence ou des résultats de référence fiables.
Une règle clé est que l’étalonnage et la validation doivent être séparés. L’étalonnage ajuste les paramètres du modèle en fonction des données. La validation teste le pouvoir prédictif sur des données indépendantes. L’utilisation du même ensemble de données pour les deux crée une confiance artificielle.
Problèmes de référence en tant que cibles de validation
Les problèmes de référence sont des cas de test standardisés avec des données de référence expérimentales ou haute fidélité bien caractérisées. Ils fournissent des objectifs de validation objectifs.
Les catégories de référence communes comprennent :
- La dynamique des fluides, telle que le flux au-delà d’un cylindre ou un écoulement de la cavité entraînée par un couvercle.
- équations de transport, telles que la diffusion 1D avec un comportement analytique connu.
- Les modèles de champs de phase, tels que les modèles Allen-Cahn ou Cahn-Hilliard, comparés au comportement de référence.
- Systèmes de réaction à la diffusion, tels que la validation de la vitesse des vagues Fisher-KPP.
Pour la modélisation des matériaux informatiques et l’apprentissage automatique basé sur les PDE, les ensembles de données de référence tels que pdebench peuvent fournir des problèmes de référence standardisés.
Lorsque les données expérimentales ne sont pas disponibles
Des données expérimentales de haute qualité ne sont pas toujours disponibles. Dans ce cas, vous pouvez toujours créer des preuves de validation en utilisant les meilleures alternatives disponibles.
- Utilisez des solutions de référence haute fidélité, telles que le DNS pour les flux turbulents, lorsqu’ils sont disponibles.
- Comparez avec des solutions analytiques pour des cas simplifiés.
- Effectuez des comparaisons de codes croisés avec des codes indépendants et bien vérifiés.
- Soyez transparent sur les limites et caractérisez l’incertitude prédictive grâce à l’analyse de sensibilité.
Stratégie de validation hiérarchique
Une stratégie de validation pratique doit être hiérarchique.
- Commencez par de simples problèmes de référence qui isolent la physique spécifique.
- Construisez la complexité grâce à des tests au niveau du système qui combinent plusieurs phénomènes.
- Documentez les problèmes de validation, les résultats, les mesures d’erreur et les conclusions sur l’adéquation de l’utilisation prévue.
Un modèle est rarement parfaitement validé. Il est validé à un certain niveau de précision pour une utilisation prévue spécifique.
3. Quantification de l’incertitude : mesurer la confiance dans les prévisions
La quantification de l’incertitude est le processus de caractérisation, de quantification et de propagation des incertitudes dans les entrées du modèle, les paramètres et les approximations. Il aide à évaluer comment l’incertitude affecte les résultats du modèle et la confiance des prévisions.
Aucun modèle n’est parfait, et chaque système réel comprend une variabilité et des connaissances incomplètes. UQ vous aide à comprendre non seulement ce que le modèle prédit, mais aussi à quel point cette prédiction est certaine.
Types d’incertitude
L’UQ distingue deux principales catégories d’incertitude.
| Tapez | Ce que cela veut dire | Peut-il être réduit ? | Exemples |
|---|---|---|---|
| Aléatoire | caractère aléatoire inhérent à un système | Non, c’est irréductible | Tolérances de fabrication et fluctuations environnementales |
| épistémique | Manque de connaissances sur le système | Oui, grâce à plus de données ou à de meilleurs modèles | Propriétés du matériau inconnues et conditions initiales non mesurées |
Cette distinction est importante car elle affecte le choix de la méthode UQ. L’incertitude aléatoire est généralement décrite avec des distributions de probabilité. L’incertitude épistémique peut souvent être réduite grâce à plus de mesures, de meilleurs modèles ou à un étalonnage amélioré.
Méthodes UQ : de simples à avancés
Simulation de Monte Carlo
La simulation de Monte Carlo est la méthode UQ la plus simple. Vous exécutez à plusieurs reprises le modèle avec des valeurs d’entrée échantillonnées au hasard à partir de distributions définies. Le résultat est une distribution des valeurs de sortie.
import numpy as np
# Example: propagate uncertainty in thermal conductivity.
# Assume k = 200 W/mK +/- 10%, represented as a uniform distribution.
k_samples = np.random.uniform(180, 220, size=10000)
# Simplified steady-state heat transfer:
# T = q * L / (k * A)
q = 1000
L = 0.01
A = 1.0
T = (q * L) / (k_samples * A)
print(f"Mean temperature: {np.mean(T):.2f} K")
print(
"95% confidence interval: "
f"[{np.percentile(T, 2.5):.2f}, {np.percentile(T, 97.5):.2f}] K"
)
Monte Carlo est facile à comprendre et à mettre en œuvre. Son principal inconvénient est le coût. Si chaque exécution de modèle est coûteuse, des milliers d’échantillons peuvent être peu pratiques.
Extension du chaos polynomial
L’expansion du chaos polynomial construit un modèle de substitution qui représente la sortie en tant que fonction polynomiale d’entrées incertaines. Cela peut être beaucoup plus efficace que le Monte Carlo brute lorsque chaque simulation est coûteuse.
Les outils Python tels que EasyVVUQ et EasySurrogate peuvent prendre en charge le chaos polynomial et les flux de travail UQ basés sur la substitution.
Analyse de sensibilité
L’analyse de sensibilité examine comment la variation de la sortie du modèle peut être attribuée à la variation des entrées du modèle. Il aide à identifier les paramètres qui influencent le plus les prédictions.
Deux grandes catégories sont :
- Analyse de sensibilité locale. Cela change une entrée à la fois tout en maintenant les autres fixes. C’est simple mais ne capture pas les interactions de paramètres.
- Analyse globale de sensibilité. Cela varie toutes les entrées ensemble et peut tenir compte des interactions. Les méthodes comprennent les indices SOBOL, les méthodes basées sur la régression et les méthodes basées sur les dérivés.
L’analyse de sensibilité est utile pour :
- Donner la priorité à la collecte de données en identifiant les paramètres les plus importants.
- Simplifier les modèles en fixant des paramètres qui ont un impact négligeable.
- Comprendre quels mécanismes pilotent les prédictions.
Le pipeline VVUQ intégré : tout mettre en place
Un pipeline VVUQ intégré suit un flux de travail systématique.
- Identifiez et caractérisez les incertitudes dans les entrées, les paramètres physiques et les approximations numériques.
- Effectuez la vérification du code et de la solution pour réduire les erreurs numériques, les bogues de codage et l’incertitude de discrétisation.
- Propager les incertitudes d’entrée à travers le modèle de calcul pour générer des distributions de sortie.
- Valider les prédictions du modèle par rapport à des données expérimentales contrôlées ou à des résultats de référence fiables.
- Soutenir la prise de décision avec des résultats probabilistes et informés des risques plutôt que des prédictions déterministes uniques.
En pratique, ce flux de travail peut être pris en charge par des outils tels que EasyVVUQ, FabSim3, les bibliothèques de modélisation de substitution et les systèmes de flux de travail orientés HPC.
Erreurs courantes de V&V et comment les éviter
erreurs de vérification
- En supposant que le code est sans bogue. Même les codes largement utilisés peuvent contenir des bogues non détectés. Les tests de régression avec des cas MMS peuvent détecter de nouvelles erreurs.
- négliger la précision des commandes. Sans confirmer les taux de convergence théorique, les estimations d’erreurs sont faibles.
- Utilisation de la comparaison de codes croisés comme seule méthode de vérification. Deux codes erronés peuvent convenir.
- Traiter la vérification comme une activité unique. Chaque changement de code significatif devrait déclencher une nouvelle vérification pertinente.
erreurs de validation
- Un étalonnage déroutant avec validation. Le réglage des paramètres sur les données, puis la validation par rapport aux mêmes données gonfle la confiance.
- ignorant l’incertitude expérimentale. Un écart peut être acceptable si l’incertitude expérimentale est supérieure à la différence.
- extrapoler au-delà du régime validé. Un modèle validé dans un seul régime ne doit pas être confié à un régime très différent sans preuves supplémentaires.
- Mauvaise documentation. Sans enregistrements de validation détaillés, la crédibilité de la simulation est difficile à évaluer.
Erreurs spécifiques à l’UQ
- En supposant que UQ est facultatif. Sans limites d’incertitude, une simulation validée n’a toujours pas d’intervalle de confiance utilisable.
- Ignorer les interactions des paramètres. Une analyse de sensibilité unique peut manquer les effets d’interaction que les méthodes globales capturent.
- Traiter toute incertitude comme aléatoire. Une certaine incertitude est épistémique et peut être réduite grâce à de meilleures données ou à de meilleurs modèles.
Guide de décision : de combien de rigueur VVUQ avez-vous besoin ?
Le niveau de rigueur VVUQ doit correspondre aux conséquences d’une défaillance du modèle.
| Situation | Rigueur recommandée | Pourquoi |
|---|---|---|
| Code de recherche académique | Vérification de base avec MMS et convergence de maillage | Niveau minimum acceptable pour la crédibilité |
| Résultats de simulation publié | Validation et validation par rapport aux benchmarks | Prend en charge la reproductibilité et l’examen par les pairs |
| Décisions de conception industrielle | VVUQ complet avec des limites UQ | Les choix de conception et la conformité peuvent dépendre du modèle |
| Applications critiques pour la sécurité | Cadre de style ASME avec examen indépendant | Les risques réglementaires et de responsabilité sont élevés |
| Substitut d’apprentissage automatique | Vérification de la précision de substitution plus UQ des limites de prédiction | Une erreur de substitution doit être quantifiée |
| Maintenance de code ou corrections de bogues | Tests MMS ciblés pour les modules concernés | Vérification rentable des chemins de code modifiés |
L’essentiel est simple : la rigueur VVUQ doit correspondre aux conséquences d’un échec. Le code académique nécessite une vérification de base. Les résultats publiés nécessitent une validation plus solide. Les applications industrielles et critiques pour la sécurité nécessitent une VVUQ complète et documentée.
Résumé et étapes suivantes
La vérification, la validation et la quantification de l’incertitude ne sont pas des extras optionnels. Ils font partie intégrante de la simulation scientifique crédible.
Un pipeline VVUQ pratique devrait suivre cette séquence :
- Commencez par la vérification du code à l’aide des MMS et des tests de précision des commandes.
- Quantifier les erreurs numériques grâce à la vérification de la solution pour les cycles de production.
- Créez des preuves de validation avec des problèmes de référence et des données indépendantes.
- Ajoutez la quantification de l’incertitude pour signaler les limites de confiance sur les prédictions.
- Suivez des normes telles que ASME VVUQ pour structurer le processus et communiquer la rigueur.
Même un programme VVUQ de base, tels que les tests MMS, la convergence de maillage et une méthode UQ, peut considérablement augmenter la confiance dans les résultats de simulation et récupérer les erreurs précoces.
Guides connexes
Pour les sujets connexes dans les flux de travail de simulation scientifique sur Matforge :
- Débogage Python pour le code scientifique : des relevés d’impression au profilage
- Quand utiliser FEM, FVM ou FDM : une comparaison pratique pour les débutants
- Méthodes de Monte Carlo pour les simulations scientifiques : un guide Python
Références et lectures complémentaires
- Roy, C.J. (2005). Examen des procédures de vérification du code et des solutions pour la simulation informatique. Journal de physique des calculs.
- Oberkampf, W.L., & Roy, C.J. (2010). Vérification et validation en informatique scientifique. Cambridge University Press.
- Portefeuille de normes ASME VVUQ : Vvuq 1, v&v 10, v&v 20
- OSTI : Introduction à la vérification, à la validation et à la quantification de l’incertitude