Discussion :

[TheGzD]

Bonjour,

c'est la première fois que je poste ici, donc soyez indulgents svp

Je sais que rien que le titre de mon post donne la migraine et que je viens juste de rejoindre votre communauté, mais je tente ma chance en espérant trouver ici quelques érudits en simulation

Pour faire bref :
je cherche une méthode (c'est-à-dire une démarche structurée et scientifique) permettant, selon une série de critères (à définir), d'évaluer différents outils de simulation (je ne demande pas forcément de mettre en évidence les métriques associées, de plus l'évaluation par rapport aux critères ne doit pas forcément aboutir à un ordonnancement, mais fournir des indicateurs (par extraction des propriétés sur lesquelles l'on souhaite faire une évaluation/comparaison)).

Je précise un peu le sens que je donne à "outil de simulation" : il s'agit ici de différentes librairies informatiques (leurs niveaux conceptuels sont donc identiques).

La méthodologie proposée ne doit pas faire état de l'influence de l'OS ni de celle du hardware.

J'ai longuement cherché des données sur le sujet sans grand succès.
Je m'adresse donc à vous en espérant que certains auront déjà trouvé des données là dessus ou seront inspirés par ce sujet

Cordialement,

GzD


PS : il ne s'agit pas ici de M&S VV&A (Modelling and Simulation Verification, Validation and Accreditation) : on suppose que les outils à évaluer permettent l'établissement de modèles répondant "correctement" aux problèmes posés. Le problème est : lequel de ces outils doit-on retenir pour la réalisation finale et pourquoi ?

PPS : n'hésite pas à me demander plus de précisions

[Lunixinclar]

Salut, bienvenue.

Tu penses à quel type de simulateur en particulier?
Tu n'as pas déjà une liste de critères? Voici quelques-uns des miens.

1) Les performances
Une appli qui rame sur du matériel high-end ne vaut pas le coup. D'autant plus que les besoins sont immenses dans le domaine de la simulation. Si l' éxécution est si lourde qu'elle requiert 100% CPU et pénalise l'ensemble du système, ça ne le fera pas.

2) La flexibilité
Un interfaçage soigné facilite la prise en main. Un langage de script embarqué est plus aisé à manipuler que l' écriture de fichiers binaires.
Si la source est fournie, tant mieux! Si pas de source, un SDK interfacera bien l'appli. Si possible dans un langage pas trop zarbi comme l' assembleur ou perl. Plus sérieusement on est moins dépendant de l' éditeur quand la source est disponible.

3) L' éditeur
Mieux vaut écarter ceux qui perturberont la continuité du produit dans le temps. Je pense en particulier à un éditeur qui change sans changer histoire de faire tourner son fond de commerce (tiens le prix est aussi un critère n'est-ce pas), sans se soucier de la rétro-compatibilité, au gré de multiples mises à jour lassantes pour les développeurs en fin de chaîne.
Un bon éditeur sait gérer les mises à jour aussi bien dans le temps que dans la quantité de changements entre les versions. C'est important parce que travailler sur une plate-forme qui n'est pas vouée à évoluer sera totalement obsolète dans cinq ans, ce qui représente une éternité à l' échelle du développeur de soft.

4) Le code et l' organisation
On préfère une petite appli à un monstre de 14 giga-octets. Plus rapide à installer, plus simple à appréhender. Selon les programmeurs la même tâche peut aller du simple au centuple quant à l' espace disque, l'organisation du code et du reste. C'est l'utilisateur final qui en fait les frais.
Un des meilleurs simulateurs sur lesquels j'ai travaillé était conçu par un allemand, avec tous les commentaires en allemand (au fond c'est le code qui compte pas le bla-bla)... Le bazard tournait à 10 FPS c'était l' horreur... Pourtant le pied tellement le simulateur était bon! Avec les années qui ont passé, quelques changements de compilateur et le matériel toujours plus performant, les performances se sont nettement améliorées du point de vue de l' utilisateur final.

[TheGzD]

Merci de m'avoir répondu aussi vite (je ne m'attendais, à vrai dire, même pas à ce que quelqu'un me réponde et encore moins aussi vite ).

Je vais reprendre les points que tu m'as proposés pour t'apporter quelques précisions, car il est vrai que j'étais resté assez vague dans mon post initial.

1) Les performances :
C'est le point clé de l'analyse que j'ai à faire il me semble, la question est donc que faire exactement ? je pense tout d'abord à élaborer des modèles d'un même problème sur chaque outil puis comparer les performances (garantie d'équivalence des modèles ? par les résultats obtenus je suppose, mais existe-t-il au moins une méthode formelle ?).

2) La flexibilité :
Je dispose seulement de librairies développées en Java :
- l'interface est une sur-couche qui devra être rajoutée ultérieurement et qui est indépendante du choix à faire
- j'ai accès à toutes les sources, car soit les librairies sont open source soit je possède les droits propriètaires
Ce côté là est indépendant je pense de l'étude que j'ai à faire.

3) L' éditeur :
Pour les mêmes raisons que précédemment ni le prix ni les mises à jour ne sont un problème. Dans le pire des cas, je peux éventuellement modifier le source à ma guise.


4) Le code et l' organisation :
Désolé mais je ne vois trop la différence entre ce point là et le premier que tu as mis en évidence.

Pour le type de simulateur, il s'agit de simulateurs capables de réaliser des modèles sur lesquels on fera de la simulation aléatoire à événements discrets.
Même si j'ai dit que je ne cherchais pas à faire de VV&A, c'est que je ne veux pas en faire (car ça n'aurait pas d'intérêt dans le cas présent) au sens conventionnel du terme. Je pense cependant qu'il faut en faire à un plus bas niveau conceptuel, c'est-à-dire au niveau des composants d'un modèle de simulation à événements discrets et donc a forciori au niveau des composants du logiciel permettant de réaliser/gérer chacun des ces aspects.

Voici la liste des composants que j'ai mis à jour (n'hésite pas à me donner ton avis et/ou me proposer des modifs ) :


I)L'état du système :
Il s'agit d'un ensemble de variables nécessaires pour décrire l'état du système à un instant donnée.

II)L'échéancier :
Un échéancier permet la gestion du temps de la simulation. Voici maintenant les différents éléments qui le composent.

II.1)L'horloge de simulation
Il s'agit dune variable qui permet de connaître le temps de simulation déjà écoulé.

II.2)La liste d'événements
Chaque élément dans cette liste contient le type de l'événement et la date de sa prochaine occurrence. Définissons brièvement ce qu'est un événement : c' est quelque chose qui provoque un changement d'état d'un objet et/ou du système.

II.3)La procédure d'initialisation
C'est un sous-programme qui initialise le modèle de simulation à l'instant du début de la simulation (généralement, l'instant 0).

II.4)Les routines d'événement
Pour chaque type d'événement , il existe une telle routine qui implémente la fonction de transformation d'état lié à cet événement. Ces routines effectuent aussi des mises à jour de la liste des événements. A la fin du traitement, chaqu'une des routines d'événement passe la main au sous-programme de gestion.

II.5)Le sous-programme de gestion
Il travaille sur les occurrences temporelles des événements contenus dans la liste d'événement. Il détermine le prochain événement à traiter, met à jour l'horloge de simulation et passe la main à la routine d'événement associée au type de l'événement en question.

III)Le générateur de variables aléatoires
Un générateur de variables aléatoires est un dispositif capable de produire une séquence de nombres dont on ne peut pas « facilement » tirer des propriétés déterministes, de façon à ce que cette séquence puisse être appelée : suite de nombres aléatoires.

Il existe plusieurs types de tels générateurs :

• les générateurs pseudo-aléatoires
• les vrais générateurs aléatoires

Pour l'étude qui nous intéresse nous ne manipulerons que des générateurs pseudo-aléatoires, car un ordinateur ne dispose pas de vraies sources de hasard. La question à se poser maintenant est : qu'attend-t-on réellement d'un générateur de nombres pseudo-aléatoires?

La réponse à cette question conditionne la méthode à choisir, car dans ce domaine tout est affaire de compromis. En général on privilégie quatre critères :

• la vitesse : il faut que le calcul du nombre pseudo-aléatoire suivant soit rapide. Il n'est pas rare de devoir générer des millions de nombres et on ne peut pas passer sa vie à attendre.
• la simplicité : c'est pour le confort du programmeur, une méthode très compliquée sera très difficile à programmer et surtout à tester.
• la méthode ne doit pas souffrir de faille grave : l'histoire des générateurs pseudo-aléatoires est pleine d'algorithmes qui se « coincent » lorsqu'ils arrivent sur un nombre particulier. Ce qui est très très gênant, car c'est souvent une source de plantages qui semblent aléatoires et qui sont par conséquent très difficiles à mettre en évidence.
• les nombres produits ne doivent pas faire apparaître de suite logique, quelle que soit la façon de les regarder : ce critère est le plus difficile à quantifier, car il dépend fortement de l'application.

IV)Le module de statistiques
Le genre de module statistique que nous allons proposer ne concerne théoriquement que les variables discrètes dont la valeur ne peut changer qu'à l'occasion de l'exécution d'un événement. Voici maintenant les composants essentiels d'un tel module :

• les compteurs statistiques : il s'agit des variables utilisées pour stocker des informations statistiques concernant les performances du système.
• le générateur d'états statistiques : c'est un sous-programme qui calcule les estimations, à partir des compteurs statistiques, des mesures de performance du système et qui édite ces informations à la fin de la simulation.

Pour l'instant je n'ai trouvé qu'une méthode nommé "Diehard" pour évaluer la qualité du générateur aléatoire : mon problème réside donc dans l'évaluation des autres composants

Merci d'avance à tous pour l'aide que vous allez m'apporter

[TheGzD]

Je note que mon sujet ne génére pas un énorme engoumant

Pour ceux que ça intéresserai quand même j'ai trouvé quelques éléments de réponse à l'url suivante : http://www.openbrr.org/wiki/index.php/Home

La méthodologie proposée se situe dans un contexte très générale et demande à être adaptée/paramétrée correctement. Dans quelques temps j'essayerai de détailler la méthode d'évaluation complète que je compte mettre en place.

N'hésitez pas à apporter votre pierre à l'édifice si vous vous sentez inspirés

[TheGzD]

J'exhume ce vieux post pour savoir si quelqu'un a des idées sur ce sujet. Meme si vous n'avez pas d'idées bien précise on peut toujours discuter : c'est fait pour ça un forum