Listes des travaux

Modélisation

Offrir la possibilité de définir soit même des vle::Value lorsque les données transportées sur les événements sont trop complexes ou trop difficiles à être traduite en données vle::Value (Map, Set, etc.) telles qu'elles sont définies aujourd'hui. Peut casser l'API.
Nettoyage de l'interface fonctionnelle de la classe devs::Executive (noyau DSDEVS) afin de ne pas fournir l'ensemble de l'API de graph::CoupledModel et devs::Coordinator. Casse complètement l'API des traducteurs et des modèles exécutifs.
Intégration d'un générateur de graphe de modèles basé sur les travaux préliminaire de Raphaël.
Ajouter plusieurs classes de gestion du temps, (double, entier et fractionnaire) afin de tenter de supprimer la plupart des erreurs de calculs sur les réels. Question cependant : est-ce encore quelque chose dont nous avons besoin ?
Tester la cohérence des événements lors d'un couplage ?
- Test des variables, des types, des unités
- Spécification des variables transportées par les événements dans les vpz
- Modification de la lib vpz
- Développement d'un programme externe pour la validation de la cohérence basé sur la lib vpz

Découpage des extensions par espace de nom. Le namespace vle::extension devient vle::ext et la version de l'extension apparaît ensuite sous la forme du numéro de version de VLE lorsque cette extension à été écrite. Nous aurons ainsi vle::ext::v0_6 et vle::ext::v0_7.
Passage à un noyau de simulation parallélisé. Le but de ce noyau est de paralléliser les calculs d'une même simulation sur plusieurs processeurs. L'attribution des processeurs est alors basée sur un découpage par modèles couplés. Le choix de la technologie à utiliser n'est pas arrêté :
- Une utilisation via le threads : le plus rapide, les communications entre modèles se passeront sur la même machine avec une mémoire partagée. Le problème : que faire sur les architectures de type cluster où plusieurs processeurs sont distants et donc la mémoire est inaccessible aux threads ?
- Une utilisation des bibliothèques MPI : utilisation de communication par socket, solution permettant d'exploiter un nombre quelconque de processeurs et même distants. Problème, les simulations seront plus lentes en raison du non partage de la mémoire.
- Une solution mélangeant les deux MPI + Threads : avec cette solution nous couvrons tout, le problème est la maintenance.

Intégration de pydynamics et jdynamics directement dans le dépôt VLE ?
- Faisabilité ?
- Portabilité ?

Proposer une API C, directement dans VLE, qui proposent un ensemble d'outils de manipulation du fichier vpz :
- Modifier les données ;
- Exécuter des simulations ;
- Récupérer les données : sous forme de matrice de réels, booléen, etc. Utilisation de la Glib.

Passage à un mode objet de l'API disponible dans RVLE ?
Passage à une méthode plus proche de R, par une fonction unique afin de ne pas utiliser une approche type C ?

library(rvle)
rvle.run(file="test.vpz", condition={("a", "x", 123), ...}, ...)

Un déboguer pour VLE permettant une interaction avec le noyau de simulation. Les commandes qui pourraient être réalisées :
- run : exécution d'une simulation
- next : avancement sac d'événements par sac d'événements
- print : interrogation de modèle
- push : insertion d'événement externe ou d'observation