Nous sommes heureux et fiers de vous faire part de la sortie de la version 0.5 d'OpenMOLE (Open MOdeL Experiment).
OpenMOLE est un logiciel pour le calcul scientifique et intensif ! Développé au sein de l'Institut des Systèmes Complexes (Paris), OpenMOLE est le fruit de quatre années de maturation et de confrontation aux problèmes de modélisations de chercheurs issus de nombreux domaines scientifiques (Sciences Humaines, Biologie, Physique, Géographie, Agro-alimentaire…). Il est 100% libre, 100% écrit en Scala.
Il est destiné aux modélisateurs réalisant de vastes explorations sur leurs modèles. Il permet à la fois de générer automatiquement de larges plans d'expériences (plans complets, LHS, Saltelli …) et d'exploiter la puissance d’environnement de calcul massivement parallèle type cluster ou grille de calcul. Le formalisme de workflow permet d'exprimer naturellement des traitements à accomplir en parallèle.
OpenMOLE ne requiert aucune connaissance en informatique distribuée de la part des modélisateurs. Il leur permet pourtant de réduire le temps d’exécution de leurs codes de quelques années à quelques heures.
Les principaux points forts d'OpenMOLE :
- une approche zéro déploiement : le code (C, C++, Python, java, Scala, Netlogo, etc ) est embarqué au runtime et ne nécessite pas de connaissance à priori de la présence de logiciels tierce parties sur les machines distantes ;
- un nombre de concepts de base restreint (4) :
- des Tâches (le code exécutable contenant un modèle par exemple) ;
- des Prototypes (variables typées) qui naviguent dans le workflow ;
- des Samplings (comment explorer mes données ?) ;
- des Environnements (ou s’exécutent mes jobs ?)) ;
- un développement modulaire permettant d'étendre la platforme sous forme de plugins en très peu de temps ;
- un accès optimisé et sans effort aux ressources de type grille (accès direct aux ressources, sur-soumission astucieuse des jobs, découverte automatique des machines et des éléments de stockage) ;
- une tâche spécifique pour la simulation multi-agent avec Netlogo ;
- une vérification formelle de validité du workflow (typage des Prototypes, topologie du workflow) ;
- un framework modulaire s'appuyant sur OSGi ;
- sa scalabilité : exécute des centaines de milliers de Tâches depuis un ordinateur portable ;
- une interface scriptée sous forme de DSL ;
- une interface graphique simple et ergonomique.
À venir dans les prochaines versions :
- de nouveaux environnements (ssh, cluster PBS, cloud) ;
- un format de sérialisation standardisé ;
- l'intégration de méthodes scientifiques avancées (optimisation, calibrage de modèles, analyse de sensibilité…) ;
- une intégration de visualisations génériques ;
- et tellement d'autres choses !
# 100% libre
Posté par thomasv . Évalué à 6.
Petite précision : c'est sous licence AGPLv3 d'après le site d'OpenMOLE.
# Keceze ?
Posté par rewind (Mastodon) . Évalué à 8.
Si je comprends tout bien, c'est un environnement dans lequel on peut définir des tâches, avec des entrées et des sorties, qu'on peut ensuite lancer sur n'importe quel système, et dont on peut récupérer les sorties pour les traiter. J'ai bon ?
Ma question : j'ai un programme basique déjà écrit qui fait une seule expérience (mais qui la fait bien), est-ce que je peux utiliser OpenMOLE pour faire mon plan d'expérience en passant en paramètres de ma commande les entrées et en récupérant les sorties… je ne sais trop comment ?
[^] # Re: Keceze ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 3.
Ma réponse : Oui :-) En gros, deux cas se présentent. Soit ton programme est en Java et tu peux directement intégrer tes classes avec une GroovyTask, soit tu peux utiliser une SystemExec Task pour invoquer un appel au programme binaire.
Dans le second cas, tu peux utiliser des variables provenant d'une autre tâche comme arguments de ta commande, ou bien copier des fichiers générés par un autre tâche dans ton répertoire de travail.
Bien sûr, l'invoquation d'une commande système rend l'exécution de ta mole dépendant de la plateforme. Donc, si tu veux déporter tes calculs sur d'autres machines (grille, ssh, pbs, …), il faut prévoir ton coup en ayant compilé ton programme pour la bonne architecture, et éventuellement utiliser CDE.
[^] # Re: Keceze ?
Posté par mamat . Évalué à 3.
Oui, je confirme les dires de Nicolas. J'ai ajouté une page de documentation pour expliciter quelle tâche utiliser avec quel code (http://www.openmole.org/?page_id=1663).
Merci pour ton retour, et n'hésite pas si tu as d'autres questions.
[^] # Re: Keceze ?
Posté par rewind (Mastodon) . Évalué à 2.
OK. Je correspond au deuxième cas. Mon programme est en C++. Par contre, je ne vois pas comment traiter les sorties. J'ai potentiellement plusieurs sorties (numériques), que je peux écrire dans un fichier. Mais ensuite, si je veux intégrer dans OpenMOLE (pour faire des moyennes, ou des graphes, etc), comment je peux faire ? Faut-il que je fasse des programmes qui extraient les valeurs des fichiers pour les afficher sur la sortie standard ?
[^] # Re: Keceze ?
Posté par mamat . Évalué à 3.
Ça fait partie de la doc qui n'est pas encore terminé, mais c'est assez simple. Je rajoute ça dans la doc de la SystemExecTask et je te tiens au courant.
[^] # Re: Keceze ?
Posté par rewind (Mastodon) . Évalué à 2.
J'ai oublié de répondre sur la partie «autres machines». En fait, oui, je fait mes calculs sur une machine fixe (par commodité, comme ça je peux laisser tourner la nuit), mais c'est la même archi, la même distribution, la même config, donc ça ne devrait pas poser de problème.
[^] # Re: Keceze ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 3.
OK. Ceci dit, OpenMOLE permet de spécifier combien de tâches peuvent s'exécuter simultanément (environement MultiThreading). Il est donc facile de tirer parti au mieux de ses multiples cœurs, ou du pipeline sur un seul cœur.
[^] # Re: Keceze ?
Posté par rewind (Mastodon) . Évalué à 3.
Oui, je comptais bien profiter de cette fonctionnalité. D'autant plus que j'utilise une lib qui n'est pas réentrante (que je ne citerai pas par bienséance, c'est une lib GNU), donc si on peut lancer des instances différentes, ça évite d'avoir à le faire à la main.
[^] # Re: Keceze ?
Posté par mamat . Évalué à 1.
Salut,
pour pouvoir sauver ton fichier, tu as besoin d'utiliser un Hook (une sorte de listener de workflow très simple à utiliser). Celui dont tu as besoin s'appelle Copy File, tu trouveras un exemple documenté à cette page http://www.openmole.org/?page_id=1683
Bon courage, dis nous si tu arrives à executer ta Mole !
# coquille
Posté par YuGiOhJCJ (site web personnel) . Évalué à 2.
"Il est destiné au modélisateurs" -> "Il est destiné aux modélisateurs"
[^] # Re: coquille
Posté par Benoît . Évalué à 1.
« Il leur permettant pourtant » → « Il leur permet pourtant »
[^] # Re: coquille
Posté par mamat . Évalué à 2.
bien vu mais je ne pense pas que je puisse éditer ma dépêche !
[^] # Re: coquille
Posté par BAud (site web personnel) . Évalué à 4.
les modérateurs le peuvent, Xate< l'a fait :)
[^] # Re: coquille
Posté par Xavier Teyssier (site web personnel) . Évalué à 2. Dernière modification le 22 juin 2012 à 13:46.
D'ailleurs, je croyais avoir laissé un message pour le signaler. J'envoyais même une petite pique sur la qualité des relecteurs qui ont laissés passer des fautes aussi frappantes (relecteur dont j'ai fait partie sur cette news !).
J'ai du oublier de valider…
# comparaison avec Condor ?
Posté par dleducq . Évalué à 1.
Comment se situent les fonctionnalités d'OpenMOLE par rapport à celles de Condor ?
[^] # Re: comparaison avec Condor ?
Posté par mamat . Évalué à 3.
Condor ne se situe pas au même niveau qu'OpenMOLE. Condor rentrerait (si on l'implémente un jour; et on est très motivé pour le faire) dans la catégorie des Environments. OpenMOLE permet de déléguer l’exécution de tâche sur plusieurs type environnements (pour l'instant multi-coeur, grille et dès fin juillet sur des machines distantes via ssh et sur des clusters de type PBS). cf http://www.openmole.org/?page_id=1110
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.