Peut-on utiliser deux programmes de modélisation différents pour confirmer les résultats l'un de l'autre?

Modèles informatiques

La modélisation informatique est utilisée dans divers domaines d'ingénierie. J'envisage spécifiquement l'analyse structurale ou l'analyse par éléments finis (FEA). Parfois, les modèles sont utilisés pour accélérer les calculs répétitifs qui pourraient être faits à la main. Parfois, les modèles sont utilisés pour effectuer des calculs qui ne sont pas faciles ou même possibles à faire à la main.

Vérification

Il existe quelques méthodes standard pour vérifier les résultats des modèles informatiques.

• Exécutez des modèles de vérification et confirmez que les résultats correspondent à une réponse précédemment calculée.
• Exécutez des modèles simples qui peuvent être vérifiés par des calculs manuels.
• Testez des modèles physiques.

Le problème avec les deux premières méthodes de vérification ci-dessus est qu'elles vérifient uniquement des situations spécifiques ou qu'elles vérifient uniquement les parties simples du programme.

La méthode du modèle physique peut être coûteuse pour les modèles en taille réelle et les modèles à l'échelle peuvent ne pas toujours donner les mêmes résultats que la taille réelle.

Cela laisse un vide dans les résultats qui peuvent être vérifiés. Pour tout modèle compliqué, il n'y a pas de moyen facile de vérifier que les résultats du programme sont corrects. L'ingénieur doit avoir confiance que le logiciel a produit des résultats corrects à partir du modèle.

Vérification de comparaison

Le modèle pourrait être introduit dans deux programmes différents (réalisés par des entreprises différentes). L'hypothèse est que si les résultats des deux modèles sont suffisamment similaires, les résultats devraient être corrects pour le modèle utilisé. Cela n'attraperait aucune erreur lors de la création du modèle d'origine, mais cela entraînerait des erreurs dans l'implémentation du logiciel.

• Deux programmes distincts pourraient-ils être utilisés pour vérifier la «justesse» des résultats du modèle?
• L'utilisation de cette méthode de comparaison d'un modèle dans deux programmes distincts fournirait-elle le même niveau d'assurance dans les résultats que n'importe quelle autre méthode de vérification?
• Quels pourraient être les inconvénients de l'utilisation de cette procédure?

Oui, obtenir un deuxième avis peut être utile. Cela se fait régulièrement dans les prévisions météorologiques où les solutions exactes sont inconnues, et il y a un certain jugement sur la façon d'appliquer divers facteurs.

Il y aura moins de marge de manœuvre dans quelque chose comme une analyse de contrainte de maillage par éléments finis car les équations itératives pour la résoudre seront fondamentalement les mêmes, peu importe qui a écrit le logiciel. Le vrai problème n'est pas de résoudre le maillage autant que de créer un maillage suffisamment bon en premier lieu.

Une façon d'obtenir plusieurs opinions consiste donc à faire varier les paramètres du maillage. J'espère que vous obtenez toujours à peu près la même réponse. Si vous rendez le maillage 2x plus fin et obtenez une réponse sensiblement différente, alors c'est un indice fort que le maillage d'origine n'était pas assez détaillé. Vous ne savez pas non plus avec certitude que le prochain maillage est suffisamment détaillé sans en créer un plus détaillé et obtenir la même réponse.

Bien sûr, de nos jours, la génération de maillage est quelque peu automatisée et adaptative. Il ne s'agit plus seulement de la physique de la résolution du maillage, mais d'inclure des heuristiques sur quand et comment subdiviser. Différents logiciels peuvent varier à cet égard, il peut donc être utile d'exécuter deux programmes différents avec les mêmes données initiales.

J'écris ceci du point de vue d'un ingénieur qui développe des logiciels de simulation.

Je pense que la pratique décrite est mauvaise, et je vous recommande de ne pas utiliser deux logiciels différents pour "confirmer" les résultats.

En général, deux logiciels de modélisation différents ne peuvent pas être utilisés pour confirmer autre chose que leur similitude. Deux logiciels pourraient facilement obtenir deux réponses similaires mais erronées, surtout s'ils utilisent des modèles similaires. Je peux penser à au moins un cas où c'est certainement le cas, et Trevor Archibald en mentionne un autre. Je serais plus impressionné par deux logiciels qui utilisent des techniques de modélisation différentes pour obtenir des résultats similaires.

Ce sujet est appelé la vérification et la validation des modèles informatiques, et il a une littérature assez vaste. Je vais proposer un croquis des bases. La vérification consiste à comparer un modèle à une solution «exacte» (qui pourrait être un calcul manuel ou quelque chose de plus complexe), c'est-à-dire à vérifier les mathématiques du logiciel. Les hypothèses derrière la solution exacte peuvent être erronées, mais au moins vous voudriez vous assurer que le logiciel obtient la bonne partie mathématique. La validation consiste à comparer un modèle à une expérience. Cela vous permet de vérifier si le modèle que vous utilisez est précis, ce que la vérification ne peut pas faire pour vous.

Le problème avec les deux premières méthodes de vérification ci-dessus est qu'elles vérifient uniquement des situations spécifiques ou qu'elles vérifient uniquement les parties simples du programme.

C'est un vrai problème auquel sont confrontés les développeurs et les utilisateurs de logiciels. Il existe des moyens établis de le gérer qui sont bien meilleurs que de comparer deux logiciels différents.

Le problème est que vous ne pouvez jamais tester tous les cas possibles. Votre logiciel peut passer le cas A, mais le cas A n'implique pas la physique X, Y ou Z, et cela vous rend totalement hors du cas B. Donc, ce que vous voudriez, c'est un grand nombre de vérifications qui couvrent au moins la totalité des les fonctionnalités de base que vous souhaitez vérifier. De nombreux logiciels ont des "suites V&V" qui sont essentiellement exactement cela.

En termes de vérification, il existe de nombreuses options. Vous pouvez générer de nouvelles solutions exactes pour différents cas. Parfois, cela suffit à lui seul. Cependant, comme vous l'avez remarqué, ce que vous pouvez faire à la main est souvent limité à des cas très simples. Pour les cas plus généraux, vous pouvez utiliser une technique appelée méthode des solutions fabriquées (Google it). Cela nécessite une programmation et peut devenir compliqué, mais vous permet de tester essentiellement tout ce à quoi vous pourriez penser. (La partie désordre peut être gérée via une bibliothèque comme MASA , soit dit en passant.)

Je voudrais également souligner que contrairement à ce que suggère Olin Lathrop, avec la méthode des solutions fabriquées, vous pouvez générer des solutions exactes à des fins de test. Ils ne sont pas «exacts» au sens strict, car ils ne satisfont pas exactement les équations que le logiciel résout sans modification. Mais ils satisfont des équations qui sont très proches, et la différence est prise en compte pour rendre le test rigoureux. Cette technique n'est pas très populaire pour le moment, mais elle a été utilisée pour tester des choses qui étaient auparavant jugées difficiles à tester.

En termes de validation, vous pouvez rechercher des données plus expérimentales ou exécuter vos propres expériences.

Je pense que c'est une bonne pratique dans l'ensemble.

En utilisant deux logiciels différents, vous pouvez éviter deux types d'erreurs: 1) les erreurs qui proviennent d'un logiciel inexact (qui ne doivent pas être négligées), 2) les erreurs qui proviennent du manque d'habitude de l'utilisateur avec le logiciel (options cachées, paramètres par défaut ...).

Si les logiciels sont suffisamment différents, les chances d'obtenir deux fois les mêmes mauvais résultats sont faibles.

Cependant, les erreurs provenant d'un mauvais choix de modélisation ne peuvent pas être évitées de cette façon. Je dirais donc que le principal inconvénient est de faire trop confiance aux résultats car ils ont été confirmés par deux logiciels.

Je pense qu'il vaut mieux maîtriser un logiciel, en exécutant toutes sortes de cas de test (comparaison avec les résultats académiques par exemple), que d'utiliser plusieurs logiciels et n'ayant qu'une connaissance moyenne. De plus, je pense qu'il est préférable de connaître les bases de l'analyse FEM, et l'utilisation de seulement deux logiciels "en un clic" est une mauvaise pratique car les utilisateurs sont susceptibles de reproduire des erreurs de modélisation.

PS: Je vous écris en tant qu'utilisateur d'électromagnétisme / analyse FEM thermique (pas d'autres domaines).

Réponse du point de vue d'un ingénieur d'études

La vérification des résultats d'un programme par rapport à un autre vous donnera une certaine certitude que les résultats sont corrects. Il est peu probable de vous donner une certitude à 100%, mais ce niveau de certitude est difficile à atteindre.

Un gros problème que je vois est de pouvoir transférer le modèle d'un logiciel à un autre. Bien que l'importation / exportation de modèles soit améliorée par la plupart des éditeurs de logiciels (à cause du BIM), je ne m'attendrais pas à ce que toutes les fonctionnalités d'un modèle soient exportables. La géométrie est relativement facile à importer / exporter car le fichier d'échange ne doit contenir que des coordonnées. Mais par exemple, les versions finales des membres sont susceptibles d'être stockées très différemment par différents logiciels, donc à moins que / jusqu'à ce qu'un format d'échange de fichiers universel soit convenu, je soupçonne que beaucoup d'efforts seraient nécessaires pour reconstruire complètement un modèle dans le deuxième logiciel.

D'après ma propre expérience, les erreurs de résultats sont beaucoup plus susceptibles de provenir d'une saisie incorrecte de données ou d'hypothèses incorrectes que de logiciels mal écrits. Le temps et les efforts consacrés à l'utilisation d'un logiciel indépendant pour vérifier une réponse ne sont donc probablement pas une bonne utilisation de votre temps.

Réponse du point de vue d'un ingénieur logiciel

La vérification d'un logiciel par rapport à un autre logiciel n'est pas considérée comme une justification que votre logiciel est correct. Il est préférable de trouver des données / résultats publiés qui peuvent être utilisés pour vérifier que le logiciel donne des réponses correctes. Imaginez une réunion de vente où une société de logiciels essaie de vendre ses logiciels à une société d'ingénierie:

Ingénieur: Comment savons-nous que votre logiciel est correct?

Vendeur de logiciels: Eh bien, nous l'avons vérifié par rapport aux logiciels de nos concurrents et avons obtenu la même réponse.

Ingénieur: Vous dites donc que votre concurrent est suffisamment meilleur que vous que son logiciel est l'étalon par rapport auquel vous mesurez votre logiciel? On dirait que nous devrions plutôt acheter son logiciel!

Je suis d'accord avec les autres réponses ici, que cela en général peut être une bonne idée et aidera à garantir l'exactitude des résultats de la simulation. En termes de qualité par rapport aux autres méthodes de vérification, je dirais que les résultats connus et les tests physiques sont deux meilleures options si possible, mais les calculs manuels peuvent nécessiter une simplification excessive si le modèle est suffisamment complexe.

Ce que je veux vraiment souligner, c'est quelque chose qui n'a pas été abordé sur le dernier point: les faiblesses potentielles de cette pratique. L'utilisation de deux packages FEA différents peut détecter une particularité d'un package qui provoque une erreur, à condition que vous puissiez identifier quelle analyse est correcte et laquelle est désactivée. Cependant, il existe des limitations générales à FEA dans l'ensemble, quelle que soit la méthode ou la mise en œuvre. Les angles vifs et autres concentrateurs de stress qui provoquent des singularités dans le modèle ne changeront pas beaucoup d'un package à l'autre, ce seront toujours des points faibles. C'est là que les connaissances et l'intuition en ingénierie sont requises.

J'ai fait des simulations sur des pièces que je connais résistent facilement à certaines contraintes, et le modèle montre que la contrainte interne est 10 fois la limite d'élasticité; c'est évidemment incorrect, car il est sur un modèle de spline involute et le logiciel FEA n'aime pas cela.

Enfin, il devrait être évident que le changement de logiciel n'élimine pas les erreurs des utilisateurs. Si vous faites une erreur dans le modèle ou les paramètres, cette erreur vous gâchera, peu importe ce que vous utilisez pour l'analyser.

Les conditions aux limites et la technique de modélisation influenceront grandement les résultats. Ce que je suggère, c'est d'exécuter une version simplifiée / idéalisée (comme planaire ou axisymétrique) et une version pleine pleine et de comparer les deux.

Le problème avec deux logiciels FEA différents est que sous le capot, les solveurs vont être en grande partie les mêmes. Les différences observées proviendraient peut-être de différents critères de convergence ou d'hypothèses différentes sur la façon dont les conditions aux limites sont appliquées. Vous ne vérifiez pas le modèle, mais la capacité de chaque solveur de savoir qu'il a atteint une solution.

Je pense que les résultats de la FEA devraient être validés par des calculs de bon sens et manuels, puis par des modèles similaires mais différents (solides au lieu de poutres par exemple) et enfin par des tests physiques pour voir si les pièces échouent où et comment la FEA prédit. Le moment où une pièce tombe en panne est plus difficile car il est influencé par les processus de fabrication, les variations de matériaux et les contraintes resudiales.