Roadmap/fr

From VLE

Jump to: navigation, search

Contents

Numéros de versions

L'environnement VLE propose une règle très simple pour la compréhension de ses numéros de versions. Les trois chiffres du numéro de version représentent les versions majeures, mineures et les patchs.

  • Par exemple, pour VLE-0.4.1 (version complète 0.4.1, version 0.4) :
    • 0 : version majeure, uniquement lorsqu'une grosse étape du projet est atteinte.
    • 4 : version mineure, lors d'ajouts de nouvelles fonctionnalités dans VLE.
    • 1 : patch, les correctifs appliqués à la version courante (0.4 ici).

En point de mire pour la version, 1.0 de VLE : l'ensemble des fonctionnalités essentielles de VLE, GVLE, EOV et RVLE sont jugées suffisamment stables. Le cycle de la modélisation est réalisable entièrement en utilisant ces programmes.

version 0.9.0

  • libdevs (noyau vle)
    • devs::Dynamics::confluentTransitions : suppression du mot-clé const et du type de retour. La fonction devra gérer elle-même son comportement, via des appels aux transitions interne et externe ou avec une dynamique propre. Sachant que par défaut, la fonction appellera la transition interne puis la transition externe. Casse l'API des modèles utilisant cette fonction : 
< virtual vle::devs::Event::EventType confluentTransitions(
<             const vle::devs::Time& /* time */,
<             const vle::devs::ExternalEventList& /* extEventlist */) const
< { return Event::INTERNAL; }
> virtual void confluentTransitions(
>              const vle::devs::Time& time,
>             const vle::devs::ExternalEventList& extEventlist);
> { internalTransition(time); externalTransition(extEventList, time); }
    • Tester un échéancier de bags plutôt qu'un échéancier d'événements.
    • Passer l'échéancier des observations par un échéancier d'observateur afin de réduire le nombre d'insertions / ajouts d'événements.
    • Déplacer l'instance de devs::ModelFactory dans la bibliothèque libvlemanager afin de ne charger qu'une unique fois les plug-ins de simulation : optimisation des multi-simulations locales et par processus légers.
  • liboov (sorties de vle)
    • fusion des greffons texte, csv, rdata en un plug-in file avec les propriétés (langue du fichier, type de fichier (csv, txt, rdata, etc.).

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

Architecture informatique

  • 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.

Sous-projets

Portage de l'API devs::Dynamics

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

Unification

  • 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.

rvle

  • 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), ...}, ...)

pyvle

  • Se mettre au même niveau de rvle

MathVLE / SciVLE

  • Même interface que rvle ou pyvle mais avec les programmes Scilab et Matlab.

vle-db

  • 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

Anciennes versions

version 0.8

  • Projet global :
    • Ajout des fonctionnalités d'internationalisation.
  • VLE :
    • Mise à jour de la gestion des chemins dans VLE :
    • Suppression des variables d'environnement VLE_SIMULATOR_PATH, VLE_OOV_PATH et VLE_MODEL_PATH. Elles sont remplacées par une nouvelle qui définit dans une sous arborescence l'ensemble des greffons : VLE_HOME. Cette variable définit la position des simulateurs, des paquets et autre plug-ins de VLE. Si cette variable n'est pas définie, le chemin $HOME/.vle sous Unix ou %HOMEDRIVE%%HOMEPATH%\vle sous Windows sont utilisés.
    • Changement dans le format VPZ. Remplacement du #PCDATA de la balise output par une hiérarchie de vle::Value. Mise à jour de la DTD.
    • Suppression des macros Assert et Throw de l'API pour supprimer des incompatibilités avec les ports Python par exemple qui redéfinissent également ces macros dans l'espace de nom global.
  • GVLE :
    • Grosse mise à jour.
  • OOV :
    • Les greffons de sortie texte, rdata, csv peuvent utiliser les sorties standard ou d'erreur au lieu de fichier.
    • Les greffons de sortie texte, rdata et csv peuvent utiliser les locales pour sortir des chaînes adaptées dans la langue de l'utilisateur.

version 0.7

  • VLE :
    • Suppression des compteurs de références sur les value::Value : boost::shared_ptr avec pour conséquence un cassage d'API pour la fonction observation() de devs::Dynamics.
    • Optimisation de l'allocation des objets de type value::Value par l'allocation d'une grosse zone mémoire memory pool de boost. Gain de l'ordre de 10 à 20% suivant les modèles.
    • Ajout de la sérialisation des classes vle::value::Value. Cette modification permet de créer un flux de données binaire des données entre composants eov - vle par exemple ou pour l'intégration de la parallélisation sur processus différents (plutôt qu'un flux de données XML chaînes de caractères).
    • Remplacement du générateur aléatoire de VLE par le Mersenne Twister de boost.
    • Mise à jour des extensions équations différentielles ordinaires et équations aux différences : syntaxe et méthodes communes.
    • 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.
  • EOV :
    • Suppression du protocole de communication XML par un protocole binaire issue des travaux sur la sérialisation des values.
    • Changement du mode de fonctionnement de EOV et OOV pour la gestion des greffons graphiques. OOV en local ou distant peut maintenant sauvegarder les images produites par les greffons tandis que EOV prend en charge de manière plus propre la gestion des threads de dessin.
    • Ajout d'un greffons de visualisation de graphes.
  • GVLE :
    • Rien.
  • RVLE :
    • Rien.
  • Win32 :
    • Passage à Boost 1.38
    • Passage à Gtkmm 2.14
    • Génération d'un fichier d'aide Windows (chm) plutôt que des fichiers html.


version 0.6

  • 0.6.0 le 27 octobre
  • 0.6.0-rc3 le 6 octobre 2008
  • 0.6.0-rc2 le 29 septembre 2008
  • 0.6.0-rc1 le 15 septembre 2008
  • Intégrer le programme Gsim dans GVLE et donc dans la release de VLE. Pour rappel, GSim est une interface graphique qui permet facilement de modifier les données des conditions expérimentales et de lancer des simulation à partir d'une interface graphique : Raphaël
  • Intégrer le DESS dans le paquet des extensions. Eric
  • Intégrer le paquet rvle dans la release de VLE. Gauthier
  • Fusionner les dépôts vle.git, gvle.git, eov.git et examples.git. Gauthier
  • Intégrer les réseaux de Petri dans le paquet des extensions. Eric
  • Fusionner le dépôt gvle.git avec vle.git. Gauthier
  • Gestion des chemins : Où trouver les simulateurs et autres plugins afin de faciliter la gestion des portages. Ajouter une système où sauvegarder les chemins /usr/lib/vle-0.... etc. dans un fichier .vlerc et dans la base de registre sous windows : Corriger avec l'ajout de variables d'environnement. Gauthier
  • Ajouter de tests unitaires dans examples.git pour vérifier les fondamentaux de VLE.Gauthier
  • Passage à CPack pour simplifier les release. Gauthier
  • Eov plus user friendly. Gauthier

version 0.5

  • 0.5.2 le 21 août 2008
  • 0.5.1 le 7 juillet 2008
  • finale le 10 mai 2008
  • RC4 le 25 avril 2008
  • RC3 le 2 avril 2008
  • RC2 le 11 février 2008
  • RC1 le 5 février 2008
  • Rendre l'option -o fonctionnelle en mode manager. L'option -o permet de spécifier le nombre de processeurs lorsque l'on veut simuler un plan d'expérience.
  • Proposer une API permettant de récupérer les sorties du plugin oov::Storage dans un code C, C++, R etc.
  • Intégration d'un plugin Oov de type storage.
  • Intégration de SWIG pour les multi-langages : tester sur les langage Python Java et Mono.
  • Modification de la bibliothèque Translator pour permettre une écriture simplifiée de nouveaux traducteurs.
  • Passer VLE en licence GPL v3.0
  • Corriger le problème des modèles exécutifs à placer en fin de bag.
  • Ajout d'une mesure finale, finish, à côté des mesures timed et event.
  • Multiples initialisations : utilisation de combinaisons de conditions initiales.
  • Nouvelle API de Dynamics (finale ?) :
    • modification des fonctions processInitEvent et processExternalEvent - réception d'un bag
    • disparition de parseXML - unification avec les événements d'initialisation
    • modification du constructeur, fusion avec la fonction processInitEvents
    • modification de la nature des paramètres de getOutputFunction : ajout de la liste des événements de sortie passée par référence et renommage en output
    • les fonctions de conflit ont été simplifiées : il reste juste la définition de la priorité entre événements internes et externes, rennomeren confluentTransitions
    • les événements externes ne transportent plus la date ; elle est passée en paramètre de processExternalEvent et processInstantaneousEvent, fonctions renommées externalTransition et request
    • la fonction retourne une value au lieu d'un pointeur sur une value
  • Ajout de la value XML.
  • Ajout de sortie graphique EOV et service web ; utilisation de Cairo.
  • Changement du comportement de VLE et EOV avec l'ajout d'une liboov.
  • Modification de la représentation de la hiérarchie de modèles DEVS. Grande amélioration des performances via un gestion par table de routage des événements.
    • Suppression des objets graph::Connection, graph::Port et graph::TargetPort.
    • Ajout d'une structure de données à chaque Port.
    • Modification des ajouts et suppressions de connections et port.
    • Suppression de la fonction récursive de capture de chemin (O(n^x) avec n le nombre de connections par modèle couplé et x le nombre de modèle couplé à traverser) en fonction à itérative (O(log(n)).
  • Remplacement des values par des compteurs de références de type boost::shared_ptr de boost
  • Suppression du code des sModel et sCoupledModel.
  • Renommage des class sAtomicModel, Simulator, Coordinator.
  • Ajout de la possibilité de mettre plusieurs modèles au sein d'une même bibliothèque dynamique.
  • Ajout des chemins dynamiques pour les plugins de VLE c-à-d, simulateurs, traducteurs, flux et modèles.
  • Nouveau format XML pour les fichiers vpz et pour les flux.
  • Variable d'environnement pour la gestion des chemins des greffons.

version 0.4

  • Découpage du projet VLE en plusieurs partie : GVLE, EOV, AVLE et VLE.
  • Meilleure gestion des cadres d'expériences sur les clusters.
  • Ajout d'un flux de sortie socket simple.


Languages Langue : 

English  • Français

Retrieved from "http://www.vle-project.org/wiki/Roadmap/fr"
This page was last modified on 4 July 2010, at 16:10. This page has been accessed 2,367 times.