Projet momentanément suspendu pour cause de migration du serveur dans le Delaware - Reprise début 2008

Projet de l'Université du Texas d'El Paso et de l'Institut de recherche Scripps. Le but est de mettre en oeuvre la technique de chromatographie en phase gazeuse pour approfondir les connaissances des interactions protéine-ligand.

INSCRIPTION (code d'invitation nécessaire)

Télécharger Boinc (tutorial)

URL du projet : http://docking.cis.udel.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élèrera 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 les membres du projet.

Table des Matières

• 1 - Le Projet
• 2 - L'équipe
• 3 - La ville
• 4 - État du Projet
• 5 - Avancée 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é 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ée 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 rejoint l'UTEP en janvier 2005. Ses intérêts de recherches incluent de nouveaux algorithmes et architectures pour les ressources et les applications gourmandes en temps de calcul dans la chimie, physique, et la bio-informatique ; migration efficace de simulations à grande échelle aux systèmes de calculs globaux basés sur les ressources publiques ; l'analyse d'exécution, la modélisation et l'optimisation des simulations à grande échelle hétérogènes, sur des systèmes distribués.

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 (planification)

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'État 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 États-Unis. C'est une zone métropolitaine ayant une des 3 plus grandes croissances urbaines des États-Unis. El Paso est à mi-distance de Los Angeles et Houston et se situe dans le fuseau horaire "Mountain Time Zone".

4. État 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 fonctionner l'application Charmm sur différentes plateformes architecturales - Memo, Richard, Andre, Michela et Pat se concentrent sur les expériences qui donneront assez d'informations 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 cela a occupé 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 assurent que les résultats d'une unité seront exclusivement exécutées sur des plateformes ayant la même structure. Nous les avons actuellement classées 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 quelle façon résoudre ce problème. Une d'entre elles consiste à expérimenter les nombreuses options du compilateur disponibles pour des opérations à 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ème 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ée pour chacune de ces classes. Ceci pourrait être une solution qui pourrait s'adapter à Docking@Home. Actuellement, nous réfléchissons à 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 voir 'ulimit -s' sur vos écrans. Avec TC shell, la commande est 'limit'. Pour découvrir quelle interface vous devez faire fonctionner, exécutez la commande 'echo$SHELL'. Pour faire partir l'erreur 'exit 1', placez 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ée à /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 ont remarqué une forte activité du disque dur quand Charmm fonctionnait sur vos ordinateurs. La raison est que nous écrivons actuellement beaucoup d'informations 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 devons 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'informations. 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 toutes les 60 secondes. L'appel de fonction que les applications devraient employer pour découvrir cette information n'a pas encore été intégré dans Charmm. Nous aborderons cette question dès que Charmm c33b1 sera mis en service par les réalisateurs de Charmm à TSRI. Encore un autre 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 sur des machines sous Windows). L'utilisation du boinc_time_to_ (fonction de BOINC concernant les points 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éveloppeurs du TSRI. Charmm contient beaucoup de fonctions d'essais d'unités 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és n'ont pas encore tous réussi; et il y a quelques problèmes en compilant Charmm pour l'imper. Quand tous les essais seront réussis et que l'imper compilera, la nouvelle version sera libérée par l'équipe de Docking@Home. Nous avons déjà pré-libéré une version 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 prochaine 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 sympas du site internet est notre nouvelle bannière, qui a été conçue par deux de nos volontaires : Mlle Atomic Booty et Mlle Cori. Merci encore pour cet excellent 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 à 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 entraînent un Crash de Charmm après avoir commencé. Ceci doit être 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ée 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 constamment 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és et testés 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 !

Dernière mise à jour : 25-12-2007 12:20

Tags : docking, docking@home, chromatographie en phase gazeuse, chromatographie, ligand, protéine, Scripps, enzyme, VIH, sida

Evaluation utilisateurs

   (0 vote)