Comment tester une implémentation de solveur numérique ODE?

Je suis sur le point de commencer à travailler sur une bibliothèque de logiciels de solveurs numériques ODE , et je n'arrive pas à formuler des tests pour les implémentations du solveur. Mon ambition est que la bibliothèque, à terme, comprendra solveurs pour les problèmes de non raides et rigides, et au moins un solveur implicite (plus ou moins à égalité avec les capacités de la oderoutine en Matlab ), de sorte que les besoins de la méthodologie de test pour refléter les différents types de problèmes et critères pour différents solveurs.

Mon problème est que je ne sais pas par où commencer avec ce test. Je peux penser à différentes façons de tester la sortie d'un algorithme:

• Testez un problème qui a une solution analytique et vérifiez que la solution numérique est dans les niveaux de tolérance pour tous les points de données renvoyés. Cela nécessite la connaissance d'un certain nombre de problèmes analytiques qui présentent toutes les propriétés avec lesquelles je veux travailler avec les différents solveurs (rigidité, problèmes implicites, etc.), que je n'ai pas, du moins pas du haut de ma tête.

  Cette méthode teste les résultats d'une méthode de solveur. Ainsi, il n'y a aucune garantie que le solveur fonctionne réellement, juste qu'il fonctionne pour le problème de test donné . Par conséquent, je soupçonne qu'un grand nombre de problèmes de test sont nécessaires pour vérifier en toute confiance que le solveur fonctionne.

• Calculez manuellement la solution pour quelques pas de temps en utilisant les algorithmes que j'ai l'intention d'implémenter, puis faites de même avec les solveurs et vérifiez que les résultats sont les mêmes. Cela ne nécessite aucune connaissance de la vraie solution au problème, mais nécessite à son tour beaucoup de travail pratique.

  Cette méthode, d'autre part, ne teste que l' algorithme , ce qui est bien pour moi - si quelqu'un d' autre a prouvé que 4 ^ème ordre fonctionne Runge-Kutta, je ne me sens pas un besoin désespéré de. Cependant, je crains qu'il ne soit très difficile de formuler des cas de test, car je ne connais pas de bonne méthode pour générer les données de test (sauf peut-être à la main, ce qui demandera beaucoup de travail ...).

Les deux méthodes ci-dessus ont de sérieuses limites pour moi avec mes connaissances actuelles - je ne connais pas un bon ensemble de problèmes de test pour le premier, et je ne connais pas une bonne méthode pour générer des données de test pour le second.

Existe-t-il d'autres moyens de vérifier les solveurs numériques ODE? Y a-t-il d'autres critères sur les implémentations qui devraient être vérifiés? Existe-t-il de bonnes ressources (gratuites) pour tester les solveurs ODE ¹ ?

EDIT:
Étant donné que cette question est très large, je tiens à clarifier un peu. La suite de tests que je veux créer remplira deux objectifs principaux:

1. Vérifier que les solveurs fonctionnent comme prévu, pour les problèmes qu'ils sont censés résoudre. En d'autres termes, un solveur pour les problèmes non rigides est autorisé à utiliser des bananes sur un problème rigide, mais devrait bien fonctionner sur les problèmes non rigides. De plus, s'il existe d'autres solveurs dans la bibliothèque qui offrent une précision plus élevée, il peut ne pas être nécessaire d'appliquer des résultats très précis - juste "assez précis". Ainsi, une partie de ma question est de savoir quels tests doivent être utilisés pour quels solveurs; ou, du moins, comment raisonner pour en décider.

2. Test de santé mentale lors de l'installation de la bibliothèque. Ces tests ne doivent pas (ne doivent pas) être élaborés ou prendre du temps; juste les bases qui peuvent être exécutées en moins de 5 secondes, mais qui alerteront l'utilisateur si quelque chose est bizarre hors des cartes. Ainsi, j'ai également besoin d'un moyen de construire des tests qui sont très simples, mais qui me disent encore quelque chose sur l'état de la bibliothèque.

^{1 Oui, j'ai recherché mes yeux sur Google, mais la plupart de ce que je trouve sont des notes de cours avec des exemples très triviaux, à l'exception notable de l'ensemble de test CWI ODE de Bari que je ne sais pas si, ou comment, je pourrait utiliser à mes fins, car il traite des solveurs beaucoup plus sophistiqués que ceux que je veux tester ...}

C'est une question très large et je vais vous donner quelques éléments de réflexion (certains sont déjà inclus dans votre message, mais ils sont répétés ici pour être complets).

Ampleur des problèmes

• Vous devez définir l'interface de la façon de spécifier les problèmes.
• Allez-vous autoriser des paramètres qui peuvent être fixes ou peuvent varier pour les solutions?
• $\epsilon$
• Allez-vous permettre une précision infinie?
• Allez-vous tester la vitesse et la sensibilité à la précision numérique?
• Avez-vous choisi deux bibliothèques (peut-être plus) qui existent déjà pour comparer les résultats?
• Comment allez-vous choisir les critères d'arrêt, allez-vous utiliser différentes méthodes et laisser l'utilisateur sélectionner ou définir les leurs?
• Allez-vous mesurer l'erreur en utilisant diverses mesures et permettre à l'utilisateur d'activer et de désactiver celles-ci?
• Avez-vous regardé les packages professionnels tels que les systèmes d'algèbre informatique (CAS) et compris toutes les options qu'ils permettent?
• Allez-vous autoriser l'affichage des résultats et / ou des comparaisons et / ou des graphiques?

Recommandations concernant les problèmes

• Vous devez rédiger une spécification de test définissant la source des problèmes, l'étendue de la façon dont les problèmes ont été testés, la capture des résultats et des métriques d'exécution des routines.
• Je chercherais certainement dans d'autres bibliothèques déjà présentes pour les problèmes qu'elles utilisent (peut-être des fichiers de test).
• J'irais dans les bibliothèques des collèges et j'examinerais les livres sur les ODE et j'extirperais les problèmes de tous types, ceux avec des solutions connues sous forme fermée ou numérique.
• Cas 1: Nous voulons autant de variantes de problèmes de solution sous forme fermée que nous pouvons obtenir afin de comparer les résultats exacts et les résultats numériques.
• Cas 2: j'irais dans tous les livres d'analyse numérique que je peux trouver et capturer les exemples travaillés et les dupliquer. Je capturerais en outre les ensembles de problèmes, en particulier ceux qui ont une certaine pathologie qui existent dans la plupart des livres (sensibilité à tel ou tel type).
• Cas 3: j'irais dans différentes branches des mathématiques appliquées comme la physique, l'écologie, la biologie, l'économie, etc. al et capturer les problèmes de chacun de ces domaines pour valider que votre langage de spécification des problèmes permet de tels exemples.
• Cas 4: Je rechercherais des articles / revues qui contiennent les exemples les plus utiles où l'auteur particulier a dû modifier une approche particulière pour tenir compte d'une pathologie ou d'une étrangeté ou d'une dureté.
• Cas 5: recherchez des exemples supplémentaires sur le Web. Pour les raides , consultez les références ici et parcourez-les TOUS pour détecter les problèmes de test. Voici quelques exemples MATLAB à parcourir.

Ce n'est pas unique. Si vous consultez le livre "Méthodes numériques pour l'optimisation sans contrainte et les équations non linéaires" de Dennis et Schnabel, Annexe B, "Problèmes de test", vous pouvez voir comment ils l'ont fait. Après avoir développé l'un des plus beaux ensembles d'algorithmes que j'aie jamais vus, ils ont jeté un ensemble de problèmes qui ont rendu les choses folles. Vous avez dû peaufiner ça et là! Ils comprenaient cinq problèmes très différents et pathologiques qui mettaient à rude épreuve les capacités des solveurs. Cela m'a appris que nous pouvons continuer à lancer des problèmes sur des algorithmes qu'ils sont incapables de gérer pour une multitude de raisons. Remarque, ils ont même emprunté cet ensemble de problèmes à More ', Garbow et Hillstrom (vous pouvez également rechercher cette référence et peut-être qu'il y en a d'autres que vous pouvez utiliser comme guide).

En d'autres termes, ce n'est pas une tâche triviale. Vous avez besoin de cas de test connus-réponses qui vous permettent toujours de tester la validité des mises à jour et de ne pas casser les choses. C'est-à-dire un ensemble répétable et étendu de problèmes de faible à élevé, de facile à difficile, de possible à impossible, ... Vous avez également besoin d'une collection de problèmes que vos résolveurs ne peuvent pas gérer afin de vraiment comprendre ses limites.

Un contrôle d'intégrité que je fais contre mes solveurs ODE consiste à simplement le vérifier sur des systèmes linéaires plus petits en calculant exactement l'exponentielle de la matrice du système. c'est à dire donné

vérifier l'erreur dans

$\hat{\mathbf{u}}(t)$

Ne calculez simplement pas l'exponentielle avec l'un de vos pas dans le temps (c.-à-d. Méthode douteuse numéro 6 :) http://www.cs.cornell.edu/cv/researchpdf/19ways+.pdf )

Vous pouvez essayer d'enquêter sur la "Méthode des solutions fabriquées", qui est une méthodologie générale utilisée pour tester la mise en œuvre des codes qui résolvent les PDE (elle peut être utilisée pour trouver des erreurs mathématiques et de codage). J'imagine qu'il pourrait être adapté au travail de résolution des ODE, si votre méthodologie de solution est assez générale.

http://prod.sandia.gov/techlib/access-control.cgi/2000/001444.pdf