Massively Parallel GPU ODE Solver

Solveur GPU-ODE massivement parallèle

Intégrateur accéléré par GPU pour un grand nombre de systèmes d'équations différentielles ordinaires indépendants

Modules :

Système unique par thread v3.1

Il résout un grand nombre d’instances du même système ODE avec des conditions initiales et/ou des jeux de paramètres différents.

Systèmes couplés par bloc v1.0

Il résout un grand nombre d’instances d’un système couplé (composé de nombreux sous-systèmes) avec des conditions initiales et/ou des ensembles de paramètres différents.

Notes de version :

18 août 2020.

Système unique par thread v3.1 :

• Prise en charge de la simple et de la double précision.
• Manuel amélioré/retravaillé, par exemple un guide d'installation plus détaillé pour les utilisateurs de Windows.
• Inclusion du fichier batch make.bat pour simplifier le processus de compilation sous Windows.
• Un nouveau tutoriel (Tutoriel 5) est ajouté pour tester un exemple ayant des instances avec de très grandes différences d'échelle de temps. La courbe de performances de MPGOS est comparée aux packages de programmes odeint (C++) et DifferentialEquations.jl (Julia). MPGOS est supérieur à ces packages.
• Le tutoriel 6 (dynamique d'impact) est également étendu avec des courbes de performances, voir le point précédent. Dans ce cas, MPGOS est le seul package de programme capable de gérer des systèmes avec une dynamique d'impact (sur les GPU). Par conséquent, les comparaisons de performances ont été effectuées uniquement avec les versions CPU d'odeint et DifferentialEquations.jl.
• Modifications mineures : séparation claire des variables TimeDomain et ActualState.

Systèmes couplés par bloc v1.0 :

• Ce premier module MPGOS est prêt. Le code est conçu pour résoudre un grand nombre d’instances d’un système couplé (composé de nombreux sous-systèmes appelés unités) avec différentes conditions initiales et/ou ensembles de paramètres.
• Le module hérite de presque toutes les fonctionnalités du module Single System Per-Thread v3.1. Il existe peu de spécialités ; par exemple, la gestion des événements n'est possible qu'au niveau de l'unité ; seul le couplage explicite peut être traité sous forme matricielle ; pour plus de détails, le lecteur intéressé pourra se référer au manuel.
• Deux exemples de didacticiels sont fournis.

14 février 2020.

Système unique par thread v3.0 :

• Améliorations massives des performances. La technique de métaprogrammation de modèles introduite nous a permis de produire un code hautement optimisé. L'infiltration moyenne est de 3x, tandis que pour les systèmes de faible dimension, elle peut même atteindre un ordre de grandeur.

10 octobre 2019.

Système unique par thread v2.1 :

• Avec Template Metaprogramming, le code est entièrement modélisé pour générer du code de solveur hautement spécialisé pendant le temps de compilation (en fonction de l'algorithme et de la nécessité de gérer les événements et de produire une sortie dense). En conséquence, le système de fichiers est retravaillé.
• Petite extension : possibilité d'utiliser des paramètres partagés entiers et des accessoires entiers pour pouvoir réaliser efficacement des techniques d'indexation complexes pour des systèmes compliqués.

13 août 2019.

Système unique par thread v2.0 :

• La sortie dense est désormais prise en charge avec quelques limitations, voir le manuel. C'est une condition préalable, par exemple, pour résoudre des équations différentielles de retard.
• Le code et son interface sont grandement simplifiés et épurés. Par exemple, le pool de problèmes est complètement omis du code (il a été conservé pour des raisons historiques) et de nombreuses options possibles sont désormais liées à l'objet Solver qui peut être configuré avec une seule fonction membre.
• Le manuel est également restructuré et simplifié en fonction des retours.

9 avril 2019.

Système unique par thread v1.1 :

• Un périphérique (GPU) peut être associé à chaque objet Solver. Ainsi, la sélection des appareils est désormais gérée automatiquement.
• Un flux CUDA est automatiquement créé pour chaque objet Solver.
• Nouvel ensemble de fonctions membres pour chevaucher les calculs CPU-GPU et pour répartir facilement la charge de travail entre différents GPU dans un seul nœud. Cela inclut les opérations asynchrones de mémoire et de noyau, ainsi que les possibilités de synchronisation entre les threads CPU et les flux GPU.
• Un nombre actif de threads variable peut être spécifié dans chaque phase d'intégration pour gérer confortablement l'effet de queue.
• Deux nouveaux exemples de didacticiel sont ajoutés : a) calculs CPU et GPU qui se chevauchent à l'aide de plusieurs objets Solver b) utilisation de plusieurs GPU disponibles sur une seule machine/nœud.

14 février 2019.

Système unique par thread v1.0 :

• Ce premier module MPGOS est prêt. Le code est conçu pour résoudre un grand nombre de systèmes ODE indépendants mais identiques (les jeux de paramètres et les conditions initiales peuvent être différents) sur les GPU.
• Convivialité. Même pour ceux qui débutent en programmation C++, un cours court suffit largement pour utiliser le package du programme.
• Il existe un manuel détaillé avec des exemples de didacticiels. Par conséquent, l’utilisateur peut facilement créer son propre projet en copiant-collant des blocs de code.
• Gestion des événements efficace et robuste.
• Action définie par l'utilisateur après chaque pas de temps pour plus de flexibilité.
• "Interactions" définies par l'utilisateur après chaque pas de temps ou gestion d'événement réussi (très utile par exemple pour la dynamique d'impact, voir les exemples de didacticiels dans le manuel).
• Possibilité d'utiliser la hiérarchie de mémoire du GPU sans connaissance explicite des détails.
• Paramètre programmable par l'utilisateur pour des implémentations flexibles et le stockage des propriétés spéciales d'une trajectoire.
• Uniquement des solveurs explicites : Runge-Kutta du 4ème ordre avec un pas de temps fixe et la méthode Runge-Kutta-Cash-Karp du 4ème ordre avec estimation d'erreur intégrée du 5ème ordre. (en raison du flux de contrôle complexe des solveurs implicites, le solveur explicite fonctionne parfois mieux que les solveurs implicites, même pour des problèmes complexes).
• Seules les opérations arithmétiques en double précision sont prises en charge.
• Stocker uniquement les points finaux de chaque phase d'intégration (afin d'améliorer la vitesse). Cependant, cela pose rarement un problème, car les paramètres programmables par l'utilisateur et les interactions définies par l'utilisateur susmentionnées permettent de stocker les propriétés les plus complexes d'une trajectoire, voir la documentation.