Boinc - Equipe de la Science

INSCRIPTION

Télécharger Boinc (tutorial)

URL du projet : http://docking.utep.edu/

Systèmes d'exploitation : Linux, Linux 64 bits, Mac OS, Windows

• Début du projet : 11 septembre 2006
• Statut : Alpha test

Les résultats : domaine public

Cible étudiée

Description du projet

DAPLDS ou Dynamically Adaptive Protein-Ligand Docking System (dynamique adaptative d'assemblage moléculaire d'un système Protéine-Ligand ) est un projet en collaboration entre l'université du Texas d'El Paso, l'institut de recherche Scripps (TSRI), et l'université de Californie - Berkeley. Le projet DAPLDS permet, par la mise en exécution et l'utilisation de l'outil internet, une modélisation adaptative multi-échelle dans un environnement Chromatographique en phase gazeuse (GC), il promouvra la connaissance des détails atomiques des interactions protéine-ligand et, de ce fait, accélerera la découverte d'innovations pharmaceutiques. Les buts du projet sont :

1. D'explorer la nature multi-échelle des algorithmiques adaptés à l'assemblage protéine-ligand

2. De développer des infrastructures internet basées sur des méthodes et des modèles informatiques qui s'adapteront efficacement à ces algorithmes

Pour en Apprendre plus (en anglais) au sujet du contenu scientifique et informatique du projet Docking@Home.

Newsletter, décembre 2006

Bienvenue sur la première newsletter du projet Docking@Home que vous recevrez régulièrement dans votre boite mail. Elle vous informera sur le statut du projet ainsi que sur ses membres du projet.

Table des Matières

• 1 - Le Projet
• 2 - L'équipe
• 3 - La ville
• 4 - Etat du Projet
• 5 - Avancé de la science
• 6 - Publications
• 7 - Quelques statistiques intéressantes
• 8 - Que nous réserve le futur

1. Le Projet

Comme la plupart d'entre vous le savent dejà, le projet Docking@Home est née de l'idée de Michela Taufer, actuellement Professeur assistant dans le service d'informatique de l'université du Texas à El Paso (UTEP). Docking@Home consiste en la mise au point d'un système de dynamique adaptative d'assemblage moléculaire d'un système Protéine-Ligand (DAPLDS : Dynamically Adaptive Protein-Ligand Docking System ). Ce projet implique une collaboration entre l'Université du Texas à El Paso (UTEP), l'institut de recherche Scripps (TSRI), et l'université de Californie à Berkeley. Le projet mettra en oeuvre une modélisation adaptative multi-échelle dans un environnement de calcul volontaire et promouvra la connaissance des interactions protéine-ligand au niveau atomique. Ainsi celà accélèrera la découverte de nouveaux produits pharmaceutiques. Les buts du projet sont :

1. D'explorer la nature multi-échelle des algorithmiques adaptés à l'assemblage protéine-ligand.

2. De développer des infrastructures internet basées sur des méthodes et des modèles informatiques qui s'adapteront efficacement à ces algorithmes.

2. L'équipe

L'équipe du projet Docking@Home est composé d'enseignants, de chercheurs et d'étudiants. Voici la liste :

Directrice du projet (Principal Investigator, PI) : Michela Taufer est professeur assistant dans le Département d'informatique de l'université du Texas à El Paso (UTEP) et directrice du projet Docking@Home. Michela a rejoinds l'UTEP en janvier 2005. Ses intérêts de recherches incluent de nouveaux algorithmes et architectures pour les ressource et les applications gourmandes en temps de calcul dans la chimie, physique, et la bio-informatique ; migration efficace de grande échelle simulations aux systèmes de calcul globaux basés sur les ressources publiques ; et l'analyse d'exécution, modeler et l'optimisation des simulations à grande échelle sur hétérogène, ont distribué des systèmes.

David Flores, Développeur de la simulation

Karina Escapita, Webmastrice

Roger Armen, Spécialiste de l'application Charmm (Chemistry at HARvard Macromolecular mechanics)

Andre Kerstens, Développeur de l'application

Richard Zamudio, Développeur de l'application

Trilce Estrada, Experte en Scheduling

D'autres membres

3. La ville

El Paso se situe en plein coeur du désert de Chihuahua à l'extrême Ouest du Texas , le long du fleuve Rio Grande. La ville est frontalière de l'Etat américain du Nouveau-Mexique et du Mexique avec les montagnes de Franklin, la pointe méridionale des Rocheuses, coupant la ville El Paso en deux.

De part sa géographie occidentale classique et parce qu'elle partage une frontière internationale avec Ciudad Juarez, la riche culture mexicaine infiltre tout El Paso, de son art à son architecture, en passant par ses célébrations et sa cuisine. La superficie d'El Paso est de 400 km², faisant d'elle la quatrième plus grande ville du Texas, et la 22ème des Etats-Unis. C'est une zone métropolitaine ayant une des 3 plus grande croissance urbaine des Etats-Unis. El Paso est à mi-distance de Los Angeles et Houston et se situe dans le fuseau horaire "Mountain Time Zone".

4. Etat du Projet

Alors, quel est l'état actuel de D@H et qu'allons nous faire ?

Pour le moment, l'équipe effectue les projets secondaires suivants :

a) Faire marcher l'application Charmm sur différentes plateformes architecturales - Memo, Richard, Andre, Michela et Pat se concentrent sur les expériences qui donneront assez d'information pour s'assurer que Charmm fournit les même résultats lorsque que l'application fonctionnera sur différentes architectures ou, tout du moins sur un ensemble d'architectures. C'est un problème très important et il s'est avéré que celà à occuper une bonne partie de notre temps. C'est également une raison pour laquelle nous utilisons la redondance homogène (HR) sur BOINC pour faire tourner notre projet. Les redondances homogènes nous assure que les résultats d'une unité seront exclusivement exécutés sur des plateformes ayant la même structure. Nous les avons actuellement classés en 6 groupes.

• Windows on AMD/PII/PIII
• Windows on Intel (non-PII/III)
• Linux on AMD/PII/PIII
• Linux on Intel (non-PII/III)
• Mac Intel
• Mac PPC (pas d'application pour le moment)

Il existe de nombreuses stratégies pour découvrir la source des différences et pour savoir de quel façon résoudre ce problème. Une d'entre elles consiste à expérimenter les nombreuses options du compilateur disponibles pour des opérations de virgule flottante. Memo teste actuellement ça pour voir s'il y a une lumière au bout du tunnel. Michela a rendu visite en Hollande à l'équipe qui s'occupe du projet Leiden Classical et qui semble avoir le même type de problèmes que nous ; ils l'ont résolu en mettant en place plus de classes de redondance homogène et en partitionnant de façon dynamique la mémoire BOINC partagé pour chacune de ces classes. Ceci pourrait être une solution qui pourrait s'adapter à Docking@Home. Actuellement, nous réflichissont à ceci.

b) Correction du ulimit sur Linux - Nous avons noté que sur plusieurs distributions Linux il était nécessaire d'augmenter la limite de la "stack size" à illimité, parce que si la "stack size" est placée si basse, l'application s'arrète avec l'erreur suivante : « Charmm exited with code 1 ». Nous avons déterminé que les distributions basées sur RedHat et Debian ont besoin de cette modification. Les distributions SuSE, Slackware et Mandrake ont une "stack size" réglée sur illimité. Voici quelques instructions sur la façon dont mettre en application cette solution de contournement : Sur Bash et K shells vous devez voire 'ulimit -s' sur vos écran. Avec TC shell la commande est 'limit'. Pour découvrir quel interface vous devez faire fonctionner, exécuter la commande 'echo$SHELL'. Pour faire partir l'erreur 'exit 1', placer svp la 'stack size' sur illimité en utilisant la commande 'ulimit -s unlimited' (ou 'limit stacksize unlimited' pour les utilisateurs de TC shell) avant de démarrer le manager BOINC ou que vous l'ajoutiez à votre script run_manager.sh et/ou run_client.sh dans le dossier d'installation de BOINC. Pour les personnes qui téléchargent BOINC depuis leur distribution, ajoutez le svp au script de BOINC start qui sera très probablement situé dans /etc/init.d . Par exemple, sur Ubuntu la ligne 'ulimit -s unlimited' doit être ajouté à /etc/init.d/boinc-client. Nous devrons trouver une solution pour ce problème de 'stack size' avant que nous puissions passer en phase beta puis en phase de production.

c) Checkpointing - Bon nombre d'entre vous avez remarqué une forte activité du disque dur quand Charmm fonctionnait sur vos ordinateurs. La raison est que nous écrivons actuellement beaucoup d'information de débogage au fichier journal de Charmm : charmm.out. C'est la cause d'un bon nombre des écritures sur le disque ; puisque nous sommes en alpha test nous devrons faire ceci pour découvrir des problèmes plus facilement ; dès que nous aurons la plupart de nos problèmes urgents de résolus, nous réduirons l'écriture d'information. Un autre problème est qu'actuellement nous ne respectons pas les préférences d'écriture de disque de l'utilisateur : par exemple, beaucoup d'utilisateurs ont mis que les applications BOINC ne devrait écrire sur leur disque pas plus que toute les 60 secondes. L'appel de fonction que les applications devraient employer pour découvrir cette information n'a pas été intégré dans Charmm encore. Nous aborderons cette question dès que Charmm c33b1 sera mis en service par les réalisateurs de Charmm à TSRI. Encore un autre le problème, c'est le fait que nos points de contrôle ne sont actuellement pas atomiques et ne sont pas parfois interrompus ainsi par le programmateur dans le BOINC client ou un arrêt du système ou un gel (qui semblent se produire fréquemment dessus Machines de Windows). Utilisation du boinc_time_to_ de fonction de BOINC le point de contrôle () résoudra plus que probablement ce problème.

d) Nouvelle Version de Charmm : c33b1 - La nouvelle version de Charmm est actuellement examinée attentivement par les dévellopeurs du TSRI. Charmm contient beaucoup de fonctions d'essai d'unité qui devraient passer avant qu'une nouvelle version soit libérée à la communauté. Dans le cas de BOINC la fonctionnalité a intégré dans Charmm que les essais d'unité ont pas tous réussis encore et il y a quelques problèmes compilant Charmm pour l'imper. Quand tous les essais passent et l'imper compilent est réussi, la nouvelle version sera libérée à l'équipe de Docking@Home. Nous avons déjà pré-libéré, une non-production et une version de BOINC-less de c33b1 au jeu avec, mais ceci ne peut pas être employé sur le serveur de projet.

e) Méthodologie des Crédits accordés - La distribution des crédits pose beaucoup de problèmes . Puisque Charmm fonctionne bien mieux (lire : bien plus rapidement) sur Linux et Mac que sur Windows, des questions se posent sur le crédit que réclame un ordinateur pour le travail effectué. en premier lieu, le client BOINC pour Linux reporte des benchmarks beaucoup plus faible que ce qu'il donnerait pour le même ordinateur sous Windows. C'est dû au fait que le client BOINC sur Linux n'a pas été compilé avec toutes les optimisations en place comme le client de Windows. Ceci sera probablement corrigé dans la prochain version du client de BOINC. D'un point de vue général, le problème des crédits réclamés/accordés peut être résolu en assignant un montant fixe de crédit basé sur le travail effectué. Par exemple, ceci signifierait par exemple que l'unité A (ayant besoin de 9 milliards de FLOPs ou de 9 gigaFLOPs) rapportera 10 crédits, alors que l'unité B (ayant besoin de 18 milliards de FLOPs ou de 18 gigaFLOPs) rapportera 20 crédits. De cette façon le système de crédit est indépendant du système benchmarking de BOINC et ainsi plus juste pour vous. Au cas où vous ne sauriez pas ce que signifie FLOP = opération en virgule flottante et celà mesure les performances des ordinateurs.

f) Site internet D@H - Karina et André ont apporté beaucoup d'améliorations et de corrections au site internet de Docking@Home. Un des changements les plus sympa du site internet est notre nouvelle bannière, qui a été conçu par deux de nos volontaires : Mlle Atomic Booty et Mlle Cori. Merci encore pour cet exellent travail ! Il y a encore quelques problèmes, la possibilité de reporter des messages offensant (le petit carré rouge avec une croix sous les messages). Karina travaille pour trouver une correction à ce bug.

g) Wrapper et gestion d'erreur - Richard travaille à étendre le wrapper que nous avons mis en application pour Charmm avec des routines de gestion d'erreur plus sophistiquées. Le but est de renvoyer une information compréhensible, simple et à d'un niveau élevé aux scientifiques au cas où Charmm éprouverait un problème.

h) Crash de Charmm sur Windows 98, ME et le Millennium - Ces plateformes entraine un Crash de Charmm après avoir commencé. Ceci doit ête dû au fait que le fichier journal de Charmm, charmm.out, ne peut pas être ouvert. Nous n'avons pas encore découvert pourquoi ceci se produit sur ces plateformes. Richard recherche une issue.

i) Ecran de Veille - Karina a commencé à travailler sur un écran de veille pour l'application Charmm. Puisqu'elle vient juste de passer sa classe en infographie , nous pensons qu'elle est la plus expérimenté pour mener ce travail ! La première version de l'écran de veille sera probablement un graphique simple rebondissant sur l'écran ; plus tard nous projetons de la laisser programmer quelque chose de plus sophistiqué comme montrer l'avancement, le score ainsi que les résultats de l'assemblage protéine-ligand.

j) SimBA - Notre simulateur d'applications de BOINC est constament en développement par Trilce, David F., André, Michela et Pat. Nous avons commencé des collaborations avec World Community Grid et il est probable qu'une collaboration naisse avec l'équipe de Leiden. De nouveaux algorithmes sont programmé et testé en employant SimBA et le plus prometteur pourrait être réglé dans le cadre de BOINC.

6. Publications

Les publications/articles suivants sont le résultat du travail réalisé par le projet Docking@Home :

• M. Taufer, A. Kerstens, T. Estrada, D. A. Flores, P. Teller, “SimBA : a Discrete Event Simulator for Performance Prediction of Volunteer Computing Projects”, To appear in Proceedings of The International Workshop on Principles of Advanced and Distributed Simulation 2007, San Diego, California, June 2007
• M. Taufer, A. Kerstens, T. Estrada, D. A. Flores, R. Zamudio, P. Teller, R. Armen, C. L. Brooks III, “Moving Volunteer Computing towards Knowledge-Constructed, Dynamically-Adaptive Modeling and Scheduling”, To appear in Proceedings of The Workshop on Large-Scale, Volatile Desktop Grids 2007, Long Beach, California, March 2007
• T. Estrada, D. A. Flores, M. Taufer, P. Teller, A. Kerstens, and D. Anderson, “The Effectiveness of Threshold-based Scheduling Policies”, Proceedings of the 2nd IEEE International Conference on e-Science and Grid Technologies (eScience 2006), Amsterdam, Netherlands, December 2006
• D. A. Flores, T. Estrada, M. Taufer, P. Teller, and A. Kerstens, “SimBA : a Discrete Event Simulator for Performance Prediction of Volunteer Computing Projects”, Poster in Proceedings of SC2006, ACM/IEEE Supercomputing 06, Tampa, Florida, November 2006

7. Quelques statistiques

Voici quelques détails issus du serveur de Docking@Home.

Volontaires - 336

Volontaires actifs (crédit total > 0) - 296

Ordinateurs - 1118

Windows – 856
Intel – 579
AMD – 277
Linux – 218
Intel – 151
AMD – 67
Macintosh – 44
Intel – 29
PPC – 15

Ordinateurs actifs (crédit total > 0) - 761

Unités générés - 17000

Unités valides - 9594

Résultats générés - 60224

Résultats valides - 25617

Crédit total - 1.177.131

crédit Macintosh total - 81.325

crédit Windows total - 979.818

crédit Linux total - 115,988

8. Que nous réserve le futur

Comme vous avez pu le voir dans les précédentes sections, beaucoup a été fait dans ce projet et nous ne pourrions pas l'avoir fait sans votre aide. Quand nous aurons résolu la plupart de nos problèmes urgents (mise en service de Charmm c33b1, différences d'architecture, points de passage, crédits accordés) nous passerons à l'étape suivante (bêta test) et nous ouvrirons le projet à plus de volontaires.

Mille mercis à vous tous qui participez à l'équipe du projet Docking@Home !