Kyle Beauchamps vient de mettre en ligne un nouveau projet utilisant le core Gromacs 4 : p10433. Ce projet simule la protéine NTL9 dans un solvant explicite utilisant le modèle tip3p à une température de 300K et une pression d’une atmosphère (soit 101 325 Pa). Ce projet permet d’affiner les résultats obtenus sur GPU sur la même protéine, mais dans un modèle implicite.

L’étude sur GPU a abouti à la construction du modèle suivant :

Le projet 10433 est distribué par le serveur 171.64.65.80, il rapporte 425 points, doit être retournée de préférence en moins de 8 jours et au plus tard en moins de 16 jours. Ce projet utilise le système de bonus et dispose d’un facteur de bonus de 0,7.

Source : Forum Officiel

Dan Vanetta vient de mettre en ligne deux nouveaux projets qui simulent la vancomycine, un antibiotique de la classe des glycopeptides, ainsi que le peptide auquel il se lie. La vancomycine est un antibiotique de dernier recours utilisé pour traiter les infections résistantes à la méticilline, une forme de pénicilline utilisée pour traiter le staphylocoque doré non résistant. Récemment, des cas de résistance à la vancomycine ont été découverts, et le but de ces simulations est de comprendre ce mécanisme de résistance.

Une molécule de Vancomycine.

Projet 10720 : Vancomycine


Projet 10721 : Peptide


Ces projets sont distribués par le serveur 171.67.108.42 et assignés aux client utilisant le paramètre –advmethods.

Source : Forum Officiel

Mise à jour du 28/05 à 15H20 :
Un troisième projet vient compléter l'étude, le 10722, utilisant toujours le core Gromacs A4. Les caractéristiques sont les suivantes :

Pendant 10 ans, les équipes du projet Folding@Home ont lancé des unités de travail (WUs), des cores et des clients en utilisant un protocole d’assurance qualité (QA en anglais) qui implique de nombreuses étapes comme les tests interne (int), un beta test fermé (bet), un beta test ouvert (adv) et enfin une sortie complète (fah). Le but de cette mise à disposition progressive est d’empêcher autant que possible les unités ou les logiciels problématiques d’être distribués au plus grand nombre. Ceci permet également aux utilisateurs de choisir leur niveau de risque dans les unités ou les logiciels qu’ils utilisent.

Cependant, cela implique qu’une quantité importante de travail est réalisée en test fermé, ce qui a de nombreux désavantages. Le plus important est que tout le travail réalisé par les bêta testeurs, les modérateurs du forum officiel et le Pande Group n’est jamais visible. Cela signifie aussi que la raison pour laquelle les unités sont lancées dans leur forme actuelle n’est pas visible non plus. Et bien que l’entrée dans l’équipe d’utilisateurs qui réalise ces bêta tests fermés, c’est un obstacle à surmonter rien que pour voir ce qui se passe (et avant de décider de s’impliquer). D’un autre coté, il y a aussi pas mal d’avantages à avoir un groupe fermé, comme le fait d’avoir un groupe d’utilisateurs expérimentés capable de fournir des retours précis sur les bugs rencontrés.

Bien qu’il y ait de pour et des contre un test fermé, Vijay Pande a décidé qu’il était temps d’améliorer la transparence dans le projet Folding@Home en général, et dans le bêta test fermé en particulier. A partir de maintenant, le forum dédié au bêta test fermé (bet) sera ouvert à tous en lecture. Cependant, afin de maintenir la qualité des retours, seuls les membres de l’équipe bêta pourront écrire dans ce forum (mais comme toujours, vous pouvez demander à rejoindre cette équipe si vous êtes intéressés par le test de nouvelles WUs).

L’idée de Vijay est que ceci montrera tout le dur labeur qui est effectué pour tester les unités et que cela répondra à certaines questions qui reviennent souvent. Dans le même esprit, l’accès à l’interface de gestion des bugs du client v7 avait également été ouvert en lecture pour que tous les utilisateurs puissent suivre l’avancement du développement du nouveau client.

Il se passe de nombreuses choses en coulisses, et Vijay est très heureux de le montrer, tout en espérant que le processus sera mieux compris et apprécié par les utilisateurs.

Source : Blog de Vijay

Des changements dans le système de statistiques sont devenus nécessaires pour maintenir une cohérence entre le site et les fichiers texte d’export (comme par exemple http://fah-web.stanford.edu/daily_user_summary.txt.bz2 ). Le problème le plus important est la façon dont les passkey sont gérées et leur impact sur les classements des utilisateurs. Il faut préciser que ces modifications ne changeront pas les points attribués aux unités ou quoi que ce soit d’autre que la façon dont les utilisateurs sont listés dans les classements.

Les passkey sont un ajout relativement récent à Folding@Home qui fut introduit par le client v6 comme identifiant unique qui lie vos contributions directement à vous (et pas seulement à votre nom d’utilisateur). L’utilisation d’une passkey empêche un autre utilisateur de tricher en utilisant votre nom.

Afin que les fichiers d’export des statistiques correspondent au site Web en terme de classement des utilisateurs, il faut changer à la fois le site et les exports. Le site ignore actuellement les comptes avec passkey (ce qui était nécessaire pour faire une commande SQL count (*) rapide) alors que les fichiers d’export agrègent tous les comptes avec passkey sous le même nom d’utilisateur et les organise ensuite par somme des points pour ce nom d’utilisateur.

La solution retenue pour résoudre ce problème est de considérer chaque combinaison de nom d’utilisateur (username) et de passkey comme un participant unique en terme de classement, à la fois dans les exports que sur le site. Ceci devrait permettre aux deux de garder une cohérence. L’équipe a passé en revue les autres solution, mais rien de correspond mieux au double objectif de rapidité pour le site Web et d’être cohérent. Bien entendu, les passkey ne seront pas incluses dans le ficher d’export (celles-ci devant rester connues uniquement des utilisateurs aux quels elles appartiennent), bien qu’il soit envisagé de les distinguer en révélant les deux derniers chiffres. Ceci serait suffisant pour identifier les différents comptes sans avoir à révéler d’information critique.

Dans les jours à venir, les fichiers d’export seront au nouveau format. Après le premier mai, le site Web sera lui aussi migré à ce format. Le délai entre les deux modifications a été prévu pour que les sites de statistiques externes puissent mettre leurs scripts à jour.

Les sites de statistiques externes auront toujours le choix d’agréger les comptes selon l’ancienne méthode ou selon la nouvelle. Ces changements sont principalement mis en place pour que les statistiques officielles soient cohérentes dans les différentes formes dans lesquelles elles sont disponibles.

Source : Blog de Vijay

Avec la sortie du client v7 nécessaire au support de ce core il y a quelques jours, nous ne pouvions que nous en douter : Stanford vient d’activer le tout nouveau core 16 (OpenMM utilisant OpenCL) pour les cartes ATI/AMD.

Attention cependant, cette version est encore immature, il n’est donc pas recommandé de l’utiliser si vous ne souhaitez pas participer à son amélioration en tolérant quelques plantages et en les rapportant …

Pour recevoir des unités utilisant ce core, vous devez donc vous munir d’un client v7 configuré en advmethods, d’un GPU compatible et de drivers incluant le support d’OpenCL (tous les drivers 11.x incluant le package APP). Dans ces conditions, vous recevrez peut être (le stock est très limité pour cette première phase des tests) une unité du projet 11293.

Ce projet simule un peptide bêta amyloïde complet à haute température. Ces simulations sont très similaires à celles qui ont déjà été effectuées sur le core OpenMM CUDA (core 15) et servent de validation scientifique pour le core 16. Le projet dispose des caractéristiques suivantes (la carte de référence est une GeForce GTX 460 tout comme pour les projets core 15) :


Nous avons testé ce core avec ce projet sur une carte graphique Radeon HD 5770 (800 shader processors @ 850 MHz) overclockée à 960 MHz alimentée par un processeur Intel Core i7 920 overlocké à 3.5 GHz fonctionnant sous Windows XP avec les drivers 11.3. Sur cette machine nous obtenons 6650 PPD avec une utilisation GPU de 100%. Nous obtenons donc une efficacité de 70 PPD / W environ, ce qui représente quasiment le double de ce qu’obtenait cette carte lors de notre test. L’efficacité est également comparable à celle d’une GeForce GTX 590 …

Sur notre machine de test, le fonctionnement du core 16 est totalement transparent, et nous pouvons continuer à utiliser la machine comme d’habitude pour surfer, regarder des vidéos ou jouer.

Malheureusement, il existe quelques points noirs : le premier, est une consommation CPU et RAM élevée sur notre machine de test. Le core 16 mobilise un thread de notre i7 à 100% pour fonctionner, et il nécessite 375 Mo de RAM. Espérons que tout ceci s’améliorera au fil des optimisations à venir. Le second point est plus problématique : certains utilisateurs ont rapporté des plantages (freezes) de leur machine lorsque que le core fonctionne en parallèle de certaines applications (comme Flash par exemple). Ces plantages semblent se produirent uniquement sur les cartes équipées d’une puce Cayman (HD 6900). Les développeurs ont été capable de reproduire le problème, espérons qu’une solution sera trouvée rapidement.

A vous de nous dire comment ce core se comporte chez vous …

Source : Blog Officiel

C’est avec une certaine émotion au vu de l’attente suscitée par cette version que nous annonçons aujourd’hui la sortie du client Folding@Home dans sa 7ème version majeure en bêta ouverte après de nombreux mois de développements et de tests ! Ce client est une réécriture complète et il est disponible sur les plateformes Windows, Linux et OSX. Ce client a été développé avec dans l’optique suivante :


Téléchargement du client
Avant de continuer, il est recommandé de lire les guides disponibles dans la documentation, mais si vous être impatients, vois trouverez le client ci-dessous :

Documentation

Les guides d’installation et d’utilisation officiels peuvent être consultés ici : https://fah-web.stanford.edu/projects/FAHClient/

Une petite FAQ a également été compilée sur le forum officiel (en anglais) : http://foldingforum.org/viewtopic.php?f=67&t=18043

Fonctionnalités principales du client v7

Ce dispose de nombreuses fonctionnalités, mais voici celles qui nous paraissent les plus intéressantes !


Rapports de bugs

Bien que le client v7 ait subit de nombreux mois de test, il reste probablement quelques bugs à corriger ou fonctionnalités à implémenter voire même quelques problèmes non encore détectés, en raison de la complexité inhérente au calcul distribué, aux nombreuses fonctionnalités du client Folding@Home et à la difficulté à maintenir en conditions opérationnelles un logiciel pour Windows, Linux et OSX. Le processus de bêta test va permettre de tester les nouvelles fonctionnalités et de corriger les bugs restants avant de passer le client en version stable.

Afin d’améliorer la transparence des processus de développement utilisés à Stanford, Vijay Pande a décidé d’ouvrir le système de rapport de bugs/demande de fonctionnalisé en lecture seule à tous les utilisateurs. Chaque ticket ouvert représente un bug ou une demande de fonctionnalité. Ceci devrait vous permettre de vérifier si ce que vous souhaitez rapporter a déjà été signalé et ainsi éviter les doublons dans un soucis de transparence et d’optimisation des rapports des utilisateurs de la bêta publique. Le système utilisé est Trac et vous pouvez le consulter à l’adresse suivante : https://fah-web.stanford.edu/projects/FAHClient/report/3

Obtenir de l’aide

La documentation officielle reste le point de départ indispensable pour trouver une information, mais si ceci n’est pas suffisant, vous avez deux possibilités pour obtenir de l’aide supplémentaire :

• Le topic du client v7 sur FAH-Addict
• La section du client v7 sur le forum officiel (en anglais)
  

Conclusion

Toute l’équipe de FAH-Addict se joint à l’enthousiasme de l’équipe du projet Folding@Home autour de ce nouveau client qui marque une évolution importante dans le domaine des clients du projet et nous espérons qu’il permettra d’accélérer le rythme des découvertes du projet dans la compréhension du repliement des protéines ainsi que de la recherche de traitement pour les maladies les plus effrayantes qui touchent notre société. L’équipe de recherche tient à remercier les participants pour leurs contributions (que ce soit par la puissance de calcul qu’ils apportent au projet que par l’aide qu’ils prodiguent aux autres utilisateurs via les forums des équipes et des sites partenaires) sans lesquelles le projet Folding@Home ne pourrait pas exister.

Torturez bien ce nouveau client, et n’hésitez pas à poster votre retour d’éxpérience.

Note : le core 16 OpenMM pour AMD/ATI n’étant pas encore prêt, celui-ci n’est pas encore disponible malgré la sortie du client v7.

Note 2 : actuellement, seul FAHControl est capable de surveiller ce client ... les applications tierces ne sont pour l'instant pas compatibles.

Source : Blog de Vijay

Dans les projets 10063 à 10082, Badi' Abdul-Wahid étudie les structures mutantes du domaine WW. Les simulations se basent sur les structures découvertes par Feng Liu dans son article intitulé « An experimental survey of the transition between two-state and downhill protein folding scenarios ».

Les projets disposent des caractéristiques suivantes :


Ces projets sont configurés pour les clients monocores seulement.

Source : Forum Officiel

Peter Kasson a mis en ligne une nouvelle série de projets étudiant le virus de la grippe : les projets 6952 à 6979. Ces projets viennent compléter les études déjà réalisées par de nombreux projets SMP comme la série 6050-6078. Ce virus est un peu la mascotte du client SMP (et surtout le sujet principal d’étude du Professeur Kasson).

Ces projets sont actuellement accessibles en –advmethods et ils disposent des caractéristiques suivantes :


Source : Forum Officiel

Suite à une petite erreur de manipulation de la part de Kyle Beauchamps dans le réglage d’un de ses projets, nous avons pu découvrir une nouvelle fonctionnalité du core A4.

En effet, environ 400 clients ont reçu des unités du projet 10437 en mode SMP ! Ce projet est bien destiné aux clients monocore, et l’erreur est maintenant corrigée. Si vous avez reçu une de ces unités, pas d’inquiétudes, vos résultats seront tout de même utilisables.

Par la suite, Kyle a confirmé une fonctionnalité du core A4 version 2.27 : celui-ci peut fonctionner à la fois en mode monocore et en mode SMP. Le mode d’exécution dépend de paramètres suivant :


Si un de ces deux paramètres n’est pas rempli, seul le mode monocore sera utilisé pour le projet.

Aucun projet utilisant le core A4 n’a le mode SMP activé pour l’instant, mais on peut espérer voir les choses évoluer assez rapidement …

Sources : Forum Officiel (1) et (2)

L’équipe du projet travaille actuellement à l’amélioration du support des GPU ATI et AMD. A l’origine, AMD/ATI utilisait le langage Brook pour programmer ses GPUs, mais depuis qu’ils ont décidé d’adopter OpenCL, le support de Brook a été abandonné. Cela signifie que pour supporter les GPU ATI/AMD sous Folding@Home, il a fallu entièrement réécrire le core en utilisant le nouveau langage. C’était une grande entreprise, mais elle est en train de porter ses fruits (vous pouvez aller sur le site d’OpenMM pour obtenir les détails ainsi qu’un changelog avec des nouvelles de la progression). En raison de la décision d’ATI/AMD d’abandonner le support de Brook à l’avantage d’OpenCL, les futurs développements de core Folding@Home pour ATI/AMD ne pourront être fait qu’en OpenCL, et par conséquent, ces cores ne fonctionneront que sur des GPUs compatibles OpenCL.

Il est temps de mettre au courant les participants au projet concernant les GPUs qui seront ou non supportés à l’avenir :


A court terme, le core Brook (Fahcore_11) sera utilisé en parallèle avec le nouveau core OpenCL (Fahcore_16) afin de ne laisser personne sur le carreau. Malheureusement, cette situation ne pourra pas s’éterniser, l’arrêt définitif du Core 11 est donc prévu au 1er septembre 2011 (cette date sera peut être repoussée, mais cela donne déjà un point de repère aux plieurs concernés). Stopper le support d’une plateforme n’est jamais une décision populaire, mais dans ce cas, il n’y a pas d’autre choix étant donné l’arrêt du support du constructeur.

La bonne nouvelle est qu’ATI/AMD est fortement impliqué dans le support d’OpenCL et les équipe de Stanford sont emballées par le futur core OpenCL qui est actuellement en test. Ce core sera lancé publiquement après la sortie du client v7, puisque celui-ci sera nécessaire pour ce core.

Source : Blog de Vijay