+CISM


Logo




Rapport d'activité 2013

de la plate-forme technologique CISM
illustration2013

Rédigé par Damien François, Luc Sindic, Bernard Van Renterghem et Thomas Keutgen (responsable)
version www disponible à l'adresse http://www.cism.ucl.ac.be/Administration/Rapports/rapport2013/index.html

Le CISM en quelques mots...

Le CISM est une plateforme technologique rattachée au Secteur des Sciences et Technologies (SST). qui fournit aux chercheurs de l'Université un service de calcul intensif et de stockage de masse. Son rôle est de fournir aux chercheurs de l'Université des solutions de calcul intensif sur de puissants systèmes informatiques et des solutions de stockage sûr et sécurisé de grandes masses de données..

Un outil indispensable à la recherche

Bien que les ordinateurs de bureau soient de plus en plus puissants, les besoins en calcul et en stockage de données des chercheurs augmentent de manière bien plus grande encore, que ce soit pour de la simulation numérique, de l'optimisation, de la modélisation, etc. En 2013, l'ensemble des infrastructures gérées par le CISM ont permis à 253 utilisateurs réguliers, dont 166 de l'UCL, de générer l'équivalent de plus de 21 million d'heures de calcul informatique, et de stocker et/ou partager plus de 170 TB de données (l'équivalent de 42000 DVD). Cette activité a conduit à la parution d'un peu plus de 80 publications scientifiques.

Une expertise reconnue

Le CISM regroupe quatre gestionnaires spécialisés entretenant un savoir-faire de pointe en calcul scientifique et en gestion de parc informatique. Cette expertise est reconnue au sein des services de l'Université où le CISM intervient dans les projets de plusieurs entités: hébergement de machines de calcul statistique pour SMCS, étude d'une nouvelle salle machine avec SIPR, etc. Cette expertise est également reconnue au sein de la Fédération Wallonie-Bruxelles (FWB): les formations organisées par l'équipe du CISM ont attiré en 2013 plus de 55 chercheurs issus de chacune des universités wallonnes et bruxelloises.

2013, l'année de démarrage de nouveaux projets

Cette année, outre une réorganisation d'envergure du stockage de masse et des mises à jour importantes sur les outils de calcul, le CISM a lancé plusieurs projets qui montreront leurs effets dans les années à venir : refonte des organes de gestion, préparation d'une nouvelle salle machine, étude d'intégration réseau avec les autres universités, et enfin, la préparation d'une collaboration étroite avec IRMP/CP3.

Introduction


Le présent rapport a pour but de fournir un résumé des activités de la plate-forme technologique sectorielle Calcul Intensif et Stockage de Masse (SST/CISM) et de l'équipe qui en gère les équipements, pour l'année 2013. Le lecteur disposant de la version imprimée est invité à consulter la version électronique où les hyperliens donnent accès aux références de ce rapport. Il fait suite aux rapports annuels d'activités du CISM depuis 2004 et à ceux du Comité du Calcul Intensif (CCI) qui était en place avant l'existence du CISM. Les faits saillants de l'année 2011 y sont extraits d'une masse brute de procès-verbaux et de statistiques.

Le rôle de la plateforme, pour son aspect « calcul intensif » est d'assurer aux chercheurs de l'Université l'accès à des outils informatiques de calcul scientifique de grande puissance, appelés « grappes de calcul », ou « clusters » ; il s'agit d'ensembles d'ordinateurs présentant de très grosses configurations interconnectés de manière à combiner leurs puissances individuelles en un super-ordinateur. Le rôle « stockage de masse » consiste à offrir aux chercheurs l'accès à des infrastructures de stockage de données de grande capacité, liées à ces outils de calcul.

Les activités prises en charge par la plate-forme vont donc de l'acquisition du matériel, et de sa maintenance, au support et à la formation des chercheurs à l'utilisation de ce matériel, sur base d'une expertise de haut niveau entretenue activement au sein de l'équipe, et d'une veille technologique permanente, en collaboration avec les autres services de l'Université mais également avec les autres universités belges.

Le CISM est géré au jour le jour par l'équipe de gestion, qui comprend quatre personnes et est dirigée par le Responsable du CISM.

 La politique de gestion du CISM est définie par le Conseil de gestion du CISM, composé des représentants de tous les utilisateurs, de l'équipe de gestion et présidé par un académique nommé pour 4 ans. Le Comité de Gestion se réunit régulièrement pour définir les stratégies à moyen et long terme, préparer les éventuels projets et évaluer le fonctionnement de la plate-forme. Les procès-verbaux de ces réunions sont disponibles pour les membres de la communauté universitaire.

La suite de ce rapport présente les faits importants de 2013 (Section 1), l'évolution des organes de la plate-forme (Section 2), l'état des lieux des infrastructures (Section 3), le bilan des activités de support aux utilisateurs (Section 4), un résumé de la veille technologique effectuée (Section 5), une description des collaborations internes et externes (Sections 6 et 7) et les perspectives pour 2014 (Section 8). Les annexes reprennent les détails de la veille technologique (Annexe 1), des infrastructures (Annexes 2 et 3) ainsi que la liste des publications obtenues grâce aux outils du CISM (Annexe 4).

1. L'année 2013 en bref


En ce qui concerne le calcul intensif, le cluster MANNEBACK a été sensiblement renforcé grâce à l'apport en infrastructure des projets INDUS et OBAN du pôle SST/IMCN/NAPS. Pour le stockage de masse, malgré les besoins encore croissants de nos utilisateurs, l'équipe de gestion du CISM a décidé de renforcer la sécurisation des données stockées sur certains serveurs en augmentant le niveau de redondance des données -- le nombre de disques de parité -- et, par conséquent, de diminuer quelque peu l'importance de l'espace mis à la disposition des utilisateurs. Cet espace sera encore réduit cette année avec le déclassement prévu de Storage02.
En ce qui concerne les autres faits saillants de cette année 2013, nous noterons:
Pas moins de 87 publications ont bénéficié de l'apport essentiel des infrastructures CISM en 2013; elles sont listées à l'annexe D.

2. CISM plateforme technologique


En 2013, le CISM a décidé de modifier son Règlement d'Ordre Intérieur (ROI). Le but étant de modifier son organisation en transformant le Comité de Gestion actuel, regroupant un représentant par pôle, en Comité des Utilisateurs et en proposant la création d'un nouveau Comité de Gestion. Ce nouveau Comité de Gestion serait réduit à un représentant par Institut. Le président actuel du Comité de Gestion restera président de cette nouvelle assemblée. Ce nouvel ROI a été soumis pour approbation au bureau du Secteur des Sciences et Technologies.
Entretemps, le Conseil du Service à la Société (CSES) a remis une note au Conseil Académique proposant une ligne de conduite pour le fonctionnement des plateformes technologiques. Notre nouvel ROI rencontre l'essentiel des points proposés dans cette note mais doit encore se choisir un Institut de référence pour y répondre entièrement. Cette note nous étant parvenue en fin d'année, le choix de notre Institut de référence et par conséquent, la mise en conformité de notre nouvel ROI sont reportés à janvier 2014.
Enfin, il faut encore rappeler la réorganisation, depuis 2011, du mode de financement de notre budget de fonctionnement. Cette année, notre budget de fonctionnement a été financé pour un tiers, par le central, un tiers, par le secteur des Sciences et Technologies et, enfin,le dernier tiers par nos utilisateurs. Il en sera de même dans les années à venir. Pour la partie financée par les utilisateurs, la répartition a été étudiée sur base du taux d'occupation de nos serveurs de calcul. Le stockage de masse n'est pas concerné car il est déjà autofinancé. Le tableau suivant présente cette répartition par Secteurs, Instituts et Pôles. Les chiffres qui y sont présentés sont arrondis au centième de pour-cent. Ainsi, le pôle ELIA, qui est listé avec 0.00%, a quand même consommé 44 heures CPU. Seuls les pôles non présents dans le tableau n'ont pas du tout utilisé les ressources du CISM.

Secteurs


Instituts


Pôles


SST

99.29%

CISM

0.01%

PAN

0.01%

ELI

13.59%

ELIC

12.95%

ELIB

0.03%

ELIM

0.02%

ELIA

0.00%

ELIE

0.59%

IMCN

67.76%

MOST

0.60%

NAPS

64.12%

BSMA

3.04%

ICTM

2.80%

ELEN

2.14%

INGI

0.46%

INMA

0.20%

IMMC

14.93%

IMAP

0.08%

MEMA

8.70%

TFL

5.70%

GCE

0.45%

IRMP

0.00%

CP3

0.00%

LOCI

0.20%

LOCI

0.20%

SSH

0.06%

TALN

0,00%

TALN

0,00%

IMMAQ

0.01%

IRES

0.01%

SMCS

0.00%

IACSSHOS

0.05%

IACS

0.05%

LSM

0.00%

LSM

0.00%

SSS

0.53%

IREC

0.53%

MIRO

0.53%

DDUV

0.00%

GEHU

0.00%

EXT

0.10%

CECI

0.00%

CECI

0.00%

VUB

0.10%

VUB

0.10%







Totaux

100,00%


100,00%


100.00%

Tableau 1: Répartitions des utilisateurs de calcul intensif par Secteurs, par Instituts et par Pôles de recherche. Cette répartition a été calculée sur base de l'utilisation en temps calcul équivalent (temps CPU) des grappes MANNEBACK, GREEN, HMEM, LEMAITRE2 et des autres clusters du CÉCI auxquels nos utilisateurs ont accès. Les utilisateurs des autres universités membres du CÉCI ne sont pas pris en considération dans ce tableau.

3. Matériel et infrastructure


En 2011 et 2012, nous avions bénéficié de financements FNRS, obtenus dans le cadre du Consortium des Équipements de Calcul Intensif (CÉCI), pour l'installation des deux clusters HMEM et LEMAITRE2. En 2013, deux projets du pôle IMCN/NAPS, intitulés respectivement INDUS et OBAN, nous ont permis de renforcer la grappe MANNEBACK avec 592 nouveaux processeurs représentant une puissance théorique additionnelle de 8.4 Tflops. (1 Tflops, ou Tera flops, représente 1000 milliards d'opérations par seconde. Par comparaison, un ordinateur individuel permet d'atteindre 0.05 Tflops)


Au total, comme le montre la Figure 1, la puissance théorique cumulée de nos infrastructures a atteint en 2013 les 39 Tflops. Un tableau récapitulatif est présenté en Annexe B.

Figure 1
Figure 1: Evolution de la puissance théorique de calcul au CISM depuis 2006.

Pour ce qui concerne le service de stockage de masse, l'augmentation du niveau de sécurisation des données stockées sur les serveurs Storage04 et Storage05 nous a fait perdre une quinzaine de terabytes (TB) par rapport à l'an dernier. Aujourd'hui, le CISM met à la disposition de l'ensemble de la communauté universitaire un espace en ligne de presque 300TB. En 2014, nous prévoyons le déclassement de Storage02, dont le contrat de maintenance ne sera plus renouvelé. (1 Terabyte représente 1000 Gigabytes, soit l'équivalent d'un gros disque dur USB actuel, ou environ 250 DVD)
La répartition de cet espace sur nos serveurs est détaillée à la Figure 2. Un tableau récapitulatif est présenté en annexe C.
Le reste de cette section présente en détail les différentes infrastructures de calcul, grappes et machines interactives, et commence par la description des salles machines hébergeant ces infrastructures.
figure 2
Figure 2: Evolution de l'espace de stockage disponible au CISM depuis 2006

3.1. Les salles informatiques (Aquarium, Pyth03 et Tier2)


Les salles "Aquarium" B012 (PYTH02) du bâtiment Pythagore et “Tier-2” du bâtiment Marc de Hemptinne, construites respectivement en 2005 et 2008, sont des nœuds vitaux de l'infrastructure informatique de l'UCL. Le système de refroidissement par eau retenu par les services techniques de l'UCL est sûr et performant. L'alimentation électrique redondante (à partir de deux cabines de transformation) ainsi qu'un onduleur protègent efficacement une série d'équipements critiques. La salle Pyth03, du bâtiment Pythagore, est plus ancienne et nous ne pouvons malheureusement plus compter sur la fiabilité de son système de refroidissement. Lors des chaleurs estivales, certains serveurs doivent même être arrêtés pour limiter l'augmentation de la température de la salle.

Aujourd'hui, les 7 armoires de l'Aquarium sont occupées au maximum de leur capacité. Nous ne pouvons plus ajouter de serveurs sans devoir procéder à l'arrêt d'une machine ou d'une grappe plus ancienne. Dans l'état actuel des choses, le déploiement d'une nouvelle infrastructure, prévue en 2015, est impossible.
Nous ne pouvons malheureusement pas non plus compter sur la salle Tier-2 où nous occupons déjà en pleine capacité les deux armoires mises à notre disposition.
Le manque de place commence à être critique pour l'évolution des infrastructures du CISM. Ce constat est d'ailleurs identique pour SGSI/SIPR. Nous avons donc déposé, dès 2011, auprès des autorités de l'Université, une demande commune SGSI/SIPR – SST/CISM pour le financement d'une nouvelle salle serveurs que nous espérons opérationnelle dès 2015.

Ce projet de nouvelle salle avance bien grâce au travail efficace de ADPI/GTPL. Il est convenu de construire un nouveau bâtiment optimisé pour l'hébergement de notre infrastructure de calcul. Les demandes des permis nécessaires et la publication des cahiers des charges sont prévues pour le début de 2014 ; l'objectif étant d'atteindre une première phase de 12 armoires pour mi-2015. Une seconde phase de 8 nouvelles armoires est prévue pour 2017.

Afin d'optimiser l'usage que nous ferons des différentes salles machines de l'UCL, il a été décidé de réserver la nouvelle salle aux applications nécessitant plus de puissance par armoire, ce qui est le cas des infrastructures du CISM et de IRMP/CP3. Les deux salles actuelles seront renforcées en terme de redondance afin de répondre aux besoins du SGSI/SIPR pour lesquels il faut mettre l'accent sur la non interruption du service. La quasi totalité des deux salles actuelles leur sera ainsi réservée. A charge pour le CISM et IRMP/CP3 de déménager tous leurs serveurs dans la nouvelle salle.

Le défi de ce projet est donc double puisqu'il faut non seulement dessiner et construire une nouvelle salle machine, mais également trouver les moyens de renforcer et pérenniser les deux salles actuelles.

3.2. La grappe MANNEBACK
 
Manneback
MANNEBACK est une grappe réservée aux membres de l'UCL ; elle héberge les machines issues de projets de recherche industriels, les machines spéciales achetées pour tester des nouvelles technologies, et les machines ne trouvant pas leur place ailleurs. Ce qui en fait un cluster hétérogène, regroupant des processeurs AMD et des processeurs Intel, des nœuds avec une interconnexion rapide et à faible latence, et d'autres équipés d'accélérateurs matériels.
Même si LEMAITRE2 reste, avec une puissance de 14TFlops, l'infrastructure la plus performante du CISM, MANNEBACK gagne chaque année en puissance, atteignant aujourd'hui 10TFlops.
Dès lors, cette année, le front-end (ou serveur d'accès), qui était originellement une machine récupérée de l'ancien cluster LEMAITRE, a été remplacé par une nouvelle machine équipée de deux processeurs Intel Xeon CPU E5-2650 @ 2.00GHz (soit 16 coeurs de calcul en tout), 64GB de RAM, et 30TB de disque configurés en RAID6, de manière à pérenniser cette infrastructure.

Outre ce nouveau frontend, MANNEBACK s'est vu ajouter en 2013:

La partition INDUS a été mise en place suite à un contrat de recherche en collaboration avec des partenaires industriels. Cette partition est réservée aux activités liées à ce contrat durant la durée des travaux, et n'est disponible pour les utilisateurs n'y étant pas impliqués directement qu'en cas de surcapacité. En pratique, chacun peut y soumettre un job, mais ce job pourra être arrêté et annulé pour laisser la place aux jobs prioritaires si besoin est.

La partition OBAN est également réservée en priorité aux utilisateurs qui ont financé les machines qui la composent ; cependant, si leurs jobs ont une priorité nettement supérieure à celle des autres jobs, ils n'ont pas la possibilité d'arrêter un job en cours pour prendre sa place.

On voit sur les figures suivantes (Figures 3 & 4) le taux d'utilisation mensuelle de MANNEBACK. Partant d'une utilisation d'environ 50% des ressources jusque mai, on observe sur le graphe l'arrivée des machines INDUS en juin. Ces machines ont été immédiatement utilisées à 100%, faisant ainsi grimper l'utilisation globale de MANNEBACK à un peu moins de 80%. En septembre, les machines OBAN ont été installée. Elles ont été peu utilisées ce mois là, faisant chuter l'utilisation globale de MANNEBACK, mais les mois suivants, cela s'est de nouveau stabilisé un peu en dessous des 80% d'utilisation globale des ressources.

Les spécifications détaillées des machines composant la grappe MANNEBACK se retrouvent à l'Annexe B.
figure 3
 figure 4
Figure 3: Taux d'utilisation mensuelle de MANNEBACK.
 Figure 4: Répartition par pôle pour MANNEBACK.

3.3. La grappe Green

 
Green
La grappe GREEN a subi une cure d'amaigrissement cette année encore ; les 6 machines Dell PowerEdge 1950 qui en faisaient partie ont du être réaffectées car l'espace qu'elles occupaient a dû être restitué (Voir à ce sujet le point 3.8). Il reste donc les 6 châssis Dell M1000e originels, équipés chacun de 16 lames (blades). Chaque lame héberge un processeur dual quad-core Intel Xeon L5420 cadencés à 2.5GHz. Alors qu'initialement, la moitié de ces machines possédaient 32 GB de mémoire, et l'autre moitié, 16GB, des réorganisations ont permis de passer à 58 machines équipées de 32GB de mémoire et 38 équipées de 16GB.
 
GREEN est le dernier système en place qui fonctionne encore avec le gestionnaire de jobs SGE et un système d'exploitation ancien (Scientific Linux 5). Il rend néanmoins encore beaucoup de services aux utilisateurs qui avaient l'habitude de travailler sur cette infrastructure. Les nouveaux utilisateurs sont invités à s'orienter plutôt vers MANNEBACK.

La Figure 5 illustre ce fait en montrant l'évolution mois par mois de l'utilisation de GREEN. En début d'année, l'utilisation moyenne mensuelle était proche proche de 80%; elle a chuté graduellement pour atteindre à peine 35% en fin d'année.
figure 5
 figure 6
Figure 5: Taux d'utilisation mensuelle de GREEN.
 Figure 6: Répartition par pôle pour GREEN.

La Figure 6 montre la répartition par pôle des utilisateurs les plus actifs sur GREEN. C'est IMCN/NAPS qui est le pôle le plus représenté, ce qui est normal étant donné que NAPS fut à la base du projet d'acquisition de cette machine. Les choix techniques de GREEN ont été effectués en fonction de leurs applications. ELIC est également fort représenté.

3.4. La grappe HMEM

 
Hmem

La grappe de calcul HMEM est une infrastructure orientée calcul intensif réclamant une quantité de mémoire vive importante ; d'où le choix du nom HMEM pour « High-Memory ». Cette infrastructure, installée en février 2011, est à la disposition des utilisateurs de l'UCL pour moitié et des membres du Consortium CÉCI pour l'autre moitié.

Cette grappe est composée de 16 machines DELL (fournies par ClusterVision) 4*12 coeurs AMD Opteron 6174 dont deux sont équipés de 512 GB de RAM, 7 de 256 GB et 7 de 128 GB. Un financement d'ELIC a permis d'ajouter un huitième noeud équipé de 128 GB de RAM (HMEM17). L'ensemble est interconnecté par un réseau rapide à faible latence Infiniband QDR (40 Gbits/s). Le CISM a ajouté un serveur d'accès et de sessions interactive équipé de 2*6 coeurs AMD Opteron 4180, 64GB de RAM, et de 11TB d'espace disque pour les répertoires utilisateurs. Il permet l'identification des utilisateurs et la gestion des jobs en attente de soumission. Enfin, 3 serveurs Transtec Calleo 530 acquis en novembre 2008 (4 dual-coeur AMD Opteron et 128GB RAM) faisant anciennement partie de Lemaitre ont été ajoutés la grappe HMEM (HMEM18, 19 et 20, dans une queue « fast » de 24 heures maximum).

Le matériel qui compose HMEM est particulier car très peu de serveurs de calcul disposent d'un demi TB de RAM, et les valeurs de 128 et 256 GB sont également plus élevées que ce qui est classiquement disponible sur des serveurs de calcul. Cela permet d'y faire tourner des simulations qui ne pourraient s'exécuter ailleurs (manipulant des tableaux très grands, par exemple). Le taux d'utilisation de HMEM reste relativement élevé. C'est ce que présente la Figures 7.

figure 7
Figure 7: Taux d'utilisation mensuelle de la grappe HMEM

Le gestionnaire de jobs mis en place sur Hmem, SLURM, doit veiller au partage équilibré entre les utilisateurs des 5 universités de la FWB. La configuration choisie tient compte du fait que la machine est dédiée à 50% aux membres de l'UCL et 50% aux membres du CÉCI (dont l'UCL). A part cela, tous les utilisateurs sont mis sur le même pied. La Figure 8 présente la répartition de l'utilisation de la grappe HMEM entre les 5 universités de la FWB pour l'année 2013.
figure 8
Figure 8: Distribution des utilisateurs par université.

3.5. La grappe LEMAITRE2

 
Lemaitre2

L'accord du Consortium des équipements de Calcul Intensif CÉCI de 2010 a permis en 2011 le financement par le FNRS d'une machine “massivement parallèle”. Disposant d'un grand nombre de CPU performants interconnectés par un réseau rapide.

La grappe LEMAITRE2 est composée de 1344 coeurs de calcul Intel X5649@2.53GHz interconnectés par un réseau Infiniband QDR “(3:1) blocking”. Un système de fichiers parallélisé de type “Lustre” assure l'accès en écriture le plus rapide possible à un espace d'hébergement temporaire de données de 120 TB. Les serveurs de gestion, d'accès aux répertoires utilisateurs (contenant les données essentielles, les sources et les programmes des utilisateurs) et de gestion du système de fichiers “Lustre” (plus performant, contenant les données de production des utilisateurs) sont tous dédoublés et sécurisés via Linux High Availibility (LHA).

La grappe LEMAITRE2, avec sa puissance maximale théorique de 13.6 Tflops, est neuf fois plus puissante que sa première version LEMAITRE installée six ans plus tôt

La Figures 9 présente les taux d'utilisation mensuelle de la grappe LEMAITRE2 pour l'année 2013.
figure 9
Figure 9: Taux d'utilisation mensuelle de la grappe LEMAITRE2
La Figure 10 présente la distribution des utilisateurs par université.
figure 10
Figure 10: Distribution des utilisateurs par université


3.6. Serveurs spécifiques


Le CISM gère, en plus des grappes de calcul, quelques machines isolées dédiées au calcul interactif. Alors que les grappes de calcul demandent à ce que l'utilisateur prépare un 'job' qui sera exécuté quand les ressources sont disponibles, les machines interactives permettent à l'utilisateur d'exécuter des programmes à tout moment, mais au risque d'être confronté à une machine surchargée par une utilisation massive et simultanée par plusieurs utilisateurs.

Serveur SAS SMCS1&2 (SMCS)

En 2011, deux serveurs de calcul ont été acquis et installés en collaboration avec la plateforme technologique Service de Méthodologie et de Calcul Statistique (SSH/IMMAQ/SMCS). Ces deux machines, présentant de grosses configurations, permettent le calcul statistique sur de grosses bases de données, avec, entre autre, les logiciels statistiques SAS, STATA et R, et sont mises à disposition de la communauté universitaire.

En 2013, la gestion de ces deux machines s'est poursuivie, avec comme fait notable le remplacement de la carte mère d'une des deux machines pour cause de défaillance matérielle.

L'utilisation qui est faite de ces machines est relativement peu intensive comparativement à l'utilisation qui est faite des clusters, mais elles permettent des modes de travail que ne permettent pas les clusters, et qui sont indispensables aux chercheurs qui les utilisent.

Dans les figures qui suivent, on peut voir l'évolution de l'utilisation des processeurs (vert) et de la mémoire (bleu) des deux machines. Une utilisation au delà de 100% indique une utilisation sous-optimale de la machine ; plus de processus (instances de programmes utilisateurs) que de processeurs (et donc 'changements de contextes' fréquents car plusieurs processus se partagent un même processeur) ou plus de mémoire de travail utilisée que de mémoire disponible (et donc utilisation d'espace disque de type 'swap' pour la mémoire).
Figure 11: utilisation de SMCS1.
Figure 12:utilisation de SMCS2.




Serveur LM9 (INMA)

Début 2011 toujours, le CISM avait installé, en collaboration avec le pôle d'Ingénierie Mathématique (SST/ICTEAM/INMA), un serveur spécifique pour les applications interactives parmi lesquelles principalement Matlab et Thermocalc. En 2013, la gestion de cette machine s'est poursuivie également, avec trois interventions pour remplacement de matériel à signaler. Cette machine a une utilisation plus chaotique que les autres, avec des périodes sans charge suivie de périodes extrêmement chargées.

Figure 13:utilisation de LM9.


3.7. Les systèmes de stockage de masse


En 2013, nous avons décidé d'augmenter le niveau de sécurisation des données sur les serveurs Storage04 et Storage05 en augmentant le nombre de disques de parité sur ces machines. Cela a eu pour conséquence de diminuer quelque peu leur espace disponible (64 TB au lieu de 72 pour Storage04 et 155 TB au lieu de 162 TB pour Storage05.
Actuellement, les quatre serveurs Storage02, Storage03, Storage04 et Storage05 fournissent à la communauté universitaire 297TB d'espace disque en ligne, ce qui correspond à une diminution d'environ 5% par rapport à ce qui était disponible l'an dernier. Cet espace est réparti comme suit (voir également la Figure 2):
Cet espace disque est sécurisé: la configuration RAID des machines tolère la panne de disques, remplaçables à chaud, c'est à dire sans devoir éteindre la machine. De plus, la récupération en cas de désastre est assurée par la délocalisation des serveurs (Storage04 et Storage05 au Pythagore; Storage02 et Storage03 au Marc de Hemptinne) et la mise en place d'un système de réplication des données, activé uniquement si l'utilisateur le souhaite.
Les Figures 14 à 16 présentent la répartition des utilisateurs par Secteurs, par Instituts et par Pôles de recherche. Par rapport à l'an dernier, si ELI reste l'Institut le plus important avec les pôles ELIC et ELIE, le pôle IMMC/TFL est devenu un utilisateur important après avoir déposé près de 10 TB de données produites sur une infrastructure PRACE. La Figure 17 montre l'évolution de l'espace de stockage utilisé et son accélération ces trois dernières années. En 2014, les prévisions basées sur les estimations des utilisateurs nous annoncent une augmentation importante de l'espace utilisé. Cette augmentation sera combinée à une diminution de l'espace disponible avec le déclassement annoncé du serveur Storage02, acquis en 2009 et arrivant en fin de garantie. Un renforcement de notre infrastructure de stockage sera probablement nécessaire en 2015.

figure 14
 figure 15
Figure 14 : Répartition des utilisateurs par secteurs.
 Figure 15: Répartition des utilisateurs par instituts.
figure 16
 figure 18
Figure 16: Répartition des utilisateurs par pôles de recherche.
 Figure 17: Répartition de l'espace de stockage utilisé depuis 2008.


3.8. Déclassement des serveurs plus anciens


En 2013, deux systèmes sont arrivés en fin de contrat de maintenance. Il s'agit d'une part du cluster GREEN, et d'autre part de la machine de stockage Storage02.

GREEN a été installé en 2008 suite à un financement FNRS obtenu par le pôle Nanoscopic Physics (SST/IMCN/NAPS). Il avait été conçu de manière à minimiser la consommation électrique tout en garantissant un bon niveau de performances. Bien qu'il ait rencontré un grand nombre de problèmes relatifs aux barrettes mémoires installées, il a rendu de grands services durant plus de 5 ans. A l'heure actuelle, cependant, ce matériel devient fort gourmand en ressources comparativement aux nouvelles technologies. Par ailleurs, il occupe un place non négligeable dans les armoires, empêchant l'installation de nouveau matériel.

Ajoutant à cela le coût prohibitif du renouvellement du contrat de support, il a été décidé de ne pas renouveler celui-ci et de tabler sur les réserves en pièces détachées pour réparer les nœuds de calcul qui viendraient à tomber en panne. En cas de panne irréparable, les nœuds seront simplement désactivés.

Les utilisateurs sont invités à se tourner de préférence vers la grappe MANNEBACK.

Par ailleurs, six serveurs de calculs ayant été ajoutés à GREEN après son installation, dans une armoire n'appartenant pas au CISM on du être délogés. Ils seront réaffectés au cluster de test Leleve2 de l'équipe de gestion. Les barrettes mémoire de ces machines (8x4GB chacune) ont été réinstallées dans d'autres nœuds de GREEN pour augmenter leur mémoire de 16GB à 32GB5.

La machine de stockage Storage02 a elle aussi été reclassée. Le contrat de maintenance arrivant à terme, il a également été décidé de ne pas le reconduire au vu de l'espace disponible par ailleurs sur d'autres machines plus récentes du CISM. Elle a été reconditionnée en une zone de travail temporaire partagée sur tous les clusters, rôle pour lequel l'absence de support hardware par le fournisseur n'est pas un problème. Ce qui n'est pas le cas pour une activité de stockage sécurisé de longue durée.

3.9. Gestion et développement de l'infrastructure


L'équipe du CISM a procédé cette année à 90 interventions sur le matériel de la plate-forme. Il s'est agit principalement de gérer les problèmes des barrettes mémoire (DIMM) de GREEN, les problèmes de carte mère de LEMAITRE2 et de quelques disques durs. De ces 90 interventions, 60 ont nécessité de faire appel au fournisseur, soit pour des pièces de rechange (45) soit pour une intervention sur place (15).
Figure 18: Nombre d'intervention par type de solution.
La figure 18 liste les interventions les plus fréquentes. Les interventions intitulées 'Reset du System Event Log' et 'Mise hors tension – reboot' ne sont pas liées à un remplacement de matériel, mais seulement à un problème matériel ponctuel s'étant résolu automatiquement ou impossible à reproduire. La figure 19 propose la répartition des ces interventions par système : grappe, machine interactive ou machine de stockage. Les systèmes les plus gros sont évidemment ceux sur lesquels il faut effectuer le plus d'interventions ; il en va de même avec les systèmes les plus anciens.
Figure 19: Nombre d'interventions par système


4. Support aux utilisateurs et formations


Outre la maintenance des infrastructures, le rôle du CISM est également d'aider et de former les chercheurs, utilisateurs de ces infrastructures.

4.1 Support aux utilisateurs


Les utilisateurs peuvent contacter l'équipe du CISM en envoyant un email à egs-cism AT listes.uclouvain.be. En 2013 cette adresse email a reçu 657 emails, dont 345 concernaient une demande de création ou de renouvellement de compte CISM ou CÉCI, et 312 concernaient une demande d'aide ou de renseignement. Ces demandes d'aide portent essentiellement sur l'accès aux machines, la compilation/installation de logiciels, et la gestion des jobs. La figure ci-dessous montre la répartition des demandes en fonction des systèmes gérés par le CISM (clusters, machines interactives, passerelles, etc.).
Figure 20: Répartition des demandes en fonction des systèmes gérés par le CISM
C'est évidemment les systèmes les plus utilisés qui génèrent le plus de demandes de la part des utilisateurs, surtout s'ils sont nouveaux. On voit sur la figure que les demandes concernant GREEN sont moins importantes, que celles concernant les autres clusters, signe sans doute que seuls les anciens utilisateurs continuent à l'utiliser.

4.2 Formations


Pour permettre aux utilisateurs de tirer le maximum des ressources qui sont mises à leur disposition, des formations au calcul haute performance sur cluster sont organisées par le CISM en collaboration avec les autres universités francophones regroupées au sein du CÉCI. Les thèmes abordés vont de l'apprentissage de la ligne de commande sous Linux, pour les plus débutants, au calcul parallèle sur accélérateurs matériels pour les plus confirmés. Ces sujets sont repris dans la figure 21. Bien que non représenté sur cette figure, une formation au logiciel R sur le cluster est également régulièrement organisée, en collaboration avec la plate-forme SMCS. Les formations Python for HPC, OpenMP, et MPI sont organisées en collaboration avec le CÉCI. Les formations à Matlab, Fortran, C, et Python, ne sont, elles, pas prises en charge par le CISM.

Fig 21
Figure 21: Thèmes abordés par les formations CISM, organisés en piles de pré-requis. A noter que les formations 'Matlab', 'Fortran or C', et 'Python' ne sont pas assurées par le CISM

Un changement important dans l'organisation avait été mis en place en 2012 et a été confirmé en 2013. Les séances sont organisées autour d'une semaine intensive de trois jours pour ce qui concerne les thèmes formant le socle de compétences de base. Cette semaine est précédée d'une séance introductive au calcul haute performance et d'une séance de formation de base à Linux. Elle est suivie d'une séquence de formations plus spécifiques, à audience plus restreinte, organisées à raison d'une par semaine. Les séances se sont déroulées, comme l'année précédente, dans les salles informatiques du bâtiment Vinci, chacune étant équipée de 25 postes de travail.

Les animateurs des formations sont des membres du CISM ou du CÉCI, choisis pour leur expertise de manière à profiter au maximum des compétences distribuées au sein du CÉCI.


salle de formation
Figure 22: Vue de la salle de formation.

Deux nouvelles formations étaient au programme de cette année. Une formation au checkpointing, une technique permettant d'interrompre puis de relancer des calculs, et une formation introductive au Xeon Phi, un tout nouveau type de matériel permettant d'accélérer les calculs. Plus de 90 chercheurs se sont inscrits, venant de chacune des universités partenaires du CÉCI, avec toutefois une participation majoritaire des membres de l'UCL. La première séance a été suivie par environ 35 personnes. Les suivantes ont vu leur audience fluctuer entre 30, pour les plus populaires, et une dizaine pour les plus pointues. Une cinquantaine de certificats de participation ont été émis ; ils sont valorisés par les doctorants dans le cadre de leur formation doctorale.
Figure 23: Répartition des participants par université.
L'année précédente, des difficultés liées à l'hétérogénéité des niveaux des participants en terme d'expérience de programmation ou d'utilisation de Linux avaient été mises en évidence. Cette année, après avoir repris précisément les contenus et pré-requis des formations sur le site web, ces difficultés ne sont plus apparues.

Une enquête de satisfaction a été organisée après la dernière formation. Elle a recueilli 24 témoignages, mettant en lumière certaines difficultés à trouver la salle de formation, la difficulté de se connecter aux machines lorsqu'on avait pas suivi les premières séances, et le désir de plus de support écrit et de plus d'exercices pratiques. Un effort sera mis sur ces aspect pour les formations organisées en 2014.

5. Veille technologique


La troisième mission du CISM est de maintenir une expertise de premier plan dans les technologies mises en place au sein de la plateforme, que ce soit pour optimiser le processus d'achat du matériel et du logiciel, ou pour pouvoir proposer aux utilisateurs des solutions efficaces tant individuelles que collectives, et assurer des formations de haut niveau.

5.1. Évaluation et comparaison de différents systèmes de fichiers partagés


Les espaces de stockage devenant de plus en plus volumineux, nécessitant l'accumulation de plusieurs serveurs interconnectés, le besoin d'un système de fichiers partagé, permettant le regroupement de plusieurs serveurs de données en un seul point d'accès (ou point de montage), devient de plus en plus important. Et ce, non seulement pour un accès aux données cohérent et transparent pour l'utilisateur, mais également pour en améliorer les performances.

Différentes solutions ont été évaluées et comparées. Cette étude est détaillée en Annexe A.1.

5.2.  Mesures de performances sur différentes technologies réseau (GbE, IB et 10GbE)

Après l'installation d'infrastructures de calcul sur les cinq sites compris dans l'environnement CÉCI, l'étape suivante, pour permettre un partage efficace de ces ressources en FWB, est d'assurer une connexion réseau inter-sites efficace et permettre ainsi à chaque utilisateur de rapatrier ses données produites dans de bonnes conditions. Le raccordement des cinq sites CÉCI en 10 GbE, une technologie dix fois plus rapide que le raccordement actuel en GbE, semble donc naturel si nous voulons augmenter la bande passante des transferts inter-sites.

Cependant, le remplacement de l'infrastructure réseau par une technologie 10 GbE n'est pas nécessairement suffisant pour assurer des transferts à haut débit. De plus, certains protocoles ne sont pas nécessairement adaptés pour ce nouveau standard.

En prévision de cette mise à niveau, des cartes 10GbE ont été ajoutées aux deux serveurs d'accès de LEMAITRE2. Ces cartes sont reliées au réseau 10GbE du SRI, dans un sous-réseau public, accessible via le réseau Belnet (en 10 GbE), dans l'attente d'une mise à niveau dans les autres universités, membres du CÉCI. Ces deux serveurs d'accès sont donc interconnectés sur trois réseaux différents : GbE, Infiniband et 10GbE, avec, pour chaque réseau, un seul commutateur (switch) à traverser. Nous pouvons donc utiliser cette configuration pour effectuer nos premiers tests comparatifs.

La figure suivante présente certains résultats comparatifs obtenus avec les trois réseaux disponibles. Comme on peut le voir, le réseau GbE présente des résultats identiques, indépendamment du type de test effectué. Les réseaux 10GbE et IB, par contre, donnent d'assez bons résultats dans les tests traditionnels de performance réseau (iperf et NetPerf), mais leurs performances s'effondrent dès que l'on utilise des protocoles de transferts de fichiers (1 GB ou 10 GB). Ces performances restent meilleures que le GbE mais sont loin des 10 Gb/s que l'on pourrait attendre avec ce type de technologie.

Il est donc évident que du travail de développement devra être fait pour trouver le bon protocole de transfert inter-sites et pour l'optimiser.
Figure 24: Comparaison des performances de transferts (en Gb/s) effectués sur des réseaux GbE, IB et 10GbE
Ces tests devront bien entendu être confirmés et optimisés dans une configuration plus utile, reliant deux centres de calcul distincts.

5.3. SLURM : état des lieux

Sur chaque cluster du CISM, la gestion des ressources et des jobs est organisées par le logiciel Slurm. Il a été choisi en 2010 lors de l'installation de HMEM, pour remplacer SGE qui était jusqu'alors installé sur les clusters à l'UCL.
Le logiciel SGE était édité par la société Sun, rachetée à l'époque par Oracle, et le caractère open-source de SGE était remis en cause par son nouveau propriétaire. L'avenir de SGE et de son développement même était incertain.
Slurm apparaissait alors comme une alternative de premier choix. Le logiciel était alors encore jeune, mais présentait de belles success stories, et, même si certaines fonctionnalités manquaient, d'autres, inédites, rendaient le produit très attrayant.
Slurm est à présent soutenu par 130 contributeurs (dont Bull, Cray, Cea et Intel), et équipe la moitié des clusters du top 10 dont le Top1 Tianhe2. On compte en moyenne deux versions publiées par an, et de nouvelles fonctionnalités, liées aux enjeux modernes du calcul sur cluster (énergie, big data, etc.) à chaque nouvelle version .
Slurm est devenu le gestionnaire de jobs choisi pour tous les clusters du CÉCI, et va probablement devenir le gestionnaire de jobs pour le cluster de calcul faisant partie de la grille de calcul du LHC et géré par le Centre for Cosmology, Particle Physics and Phenomenology (SST/IRMP/CP3) également.

En 2013, l'ensemble des installations de Slurm ont été mis à jour à la version 2.6.0 d'une part pour homogénéiser le parc des clusters, mais surtout pour profiter des dernières avancées en matière de fonctionnalités dans Slurm. Ainsi, une fonctionnalité fortement demandée par les utilisateurs, le 'jobs array' , qui simplifie la gestion d'un grand nombre de 'petits' jobs indépendants, est apparue avec cette version. On peut noter également la possibilité de comptabiliser l'énergie consommée par un job, avec l'option pour l'utilisateur de diminuer la fréquence d'horloge du CPU pour consommer moins lorsque les programmes le permettent.

Dans le cadre de la collaboration avec CP3, le CISM a étudié les possibilités de calcul 'high throughput' (HTC, soit un grand nombre de petits jobs) avec Slurm et établi des benchmarks sur le cluster de test du CISM (leleve). Il est apparu de ces tests, que même avec des options gourmandes en ressources que sont la comptabilité précise par utilisateur et le calcul des priorités avec rétro-remplissage, Slurm était un candidat tout à fait viable pour le calcul HTC avec une gestion par exemple de 100000 jobs en moins d'une heure.

5.4. Comparaisons CPU – GPU – Xeon Phi

En 2013, le CISM a acquis un Xeon Phi. Il s'agit d'une technologie matérielle apparue cette année, se présentant sous la forme d'une carte d'extension venant s'insérer dans le châssis d'un ordinateur pour en améliorer les performances (accélérateur). Le Xeon Phi est vendu par Intel dans le but de concurrencer les fabricants de cartes graphiques (GPU) destinées au calcul scientifique, un autre type d'accélérateur. Le CISM possède déjà plusieurs de ces cartes graphiques.

Le Xeon Phi est venu rejoindre deux cartes graphiques nVidia M2090 dans la machine mback040 du cluster MANNEBACK. Il est ainsi disponible pour les utilisateurs pour se familiariser avec la technologie, et pour faire du développement.

L'équipe s'est également familiarisée avec cette technologie de manière à pouvoir proposer, dans le cycle de formations, une séance y consacrée, et à être capable de répondre aux questionnements des utilisateurs.

Ainsi, une petite étude comparative des Xeon Phi et des GPU (avec le framework CUDA) est reprise en Annexe A.2. Elle s'intéresse à la facilité d'utilisation et de programmation de ces accélérateurs, ainsi qu'à leurs performances relatives.

Les conclusions de cette étude montrent que les cartes graphiques, à prix équivalent, sont légèrement plus performantes que les Xeon Phi, mais sont d'une complexité de programmation plus importante, au point qu'il est recommandé de ne les utiliser que si des librairies optimisées pour GPU sont disponibles pour le type d'application considéré. A noter que le nombre de ces librairies est très important et couvre une large palette d'applications scientifiques. Le Xeon Phi est plus facile à programmer, mais demande un compilateur coûteux, compilateur que le CISM met à disposition des utilisateurs.

5.5. Evaluation de Xcat : Système de déploiement d'infrastructure


Le CISM gère quatre grappes de calcul : GREEN, MANNEBACK, HMEM et LEMAITRE2, ainsi qu'une grappe de développement, « Lélève », réservée aux tests de configurations et d'évaluations de performances. Ces différentes infrastructures possèdent différents outils de déploiement et d'installation des nœuds de calcul :
GREEN sera arrêté dans un an. Le ClusterOS management Tools, ne sera plus utilisé. Cet outil a évolué en « Bright Cluster Manager » et est mis en place pour les grappes CÉCI VEGA à l'ULB et NIC4 à l'ULg.
HP CMU nécessite l'achat de licence et n'est supporté que pour le matériel du constructeur HP.
Le système « maison » NFSroot offre une grande souplesse en production mais manque d'outil d'automatisation pour l'ajout de nouveaux nœuds. De plus, on ne peut pas facilement déployer différentes configurations pour un même nœud, ce qui est utile dans un environnement de test (après divers essais de logiciels, revenir facilement à un état antérieur, par exemple).

Xcat (Extreme Cloud Administration Toolkit) est un logiciel Open-Source développé par IBM qui permet le déploiement et l'administration de grappe de calcul sous Linux. Il est activement développé. La version 2.8.3 date du 15 novembre 2013.

Il conserve les avantages de la solution « maison » auquel on peut ajouter les facilités de déploiement de nœuds identiques ou particuliers.

6. Actions et contacts hors-CISM


6.1. La coopération CP3-CISM


Le projet TIER-2 belge a été accepté au début 2006 et consiste à se doter des moyens nécessaires à l’acquisition et au fonctionnement d’un nœud de calcul destiné à être intégré dans la grille mondiale de calcul WLCG (Worldwide LHC Computing Grid), pour le stockage et l’analyse de données des expériences auprès du Large Hadron Collider du CERN. Le TIER-2 belge est constitué de deux sites séparés, l’un à l’UCL et l’autre à l’Institut Interuniversitaire des Hautes Energies IIHE de l’ULB/VUB.

L'accord de partenariat établi en 2006 entre l'unité IRMP/CP3 et le CISM pour l'hébergement de l'infrastructure UCL dans la salle Tier2 au bâtiment Marc de Hemptinne est toujours d'application.

En 2015, lors de la mise en production de la nouvelle salle machine (voir section 3.1), il est prévu de déménager l'ensemble des infrastructures IRMP/CP3 et SST/CISM dans cette nouvelle salle. C'est une occasion unique pour rapprocher et améliorer le partage de nos ressources mutuelles. Dès à présent, un travail de fond a débuté avec les administrateurs de IRMP/CP3 pour trouver les solutions techniques adéquates permettant ce rapprochement

6.2. La coopération avec l'entité SGSI/SIPR


Pour rappel, le CISM occupe actuellement 13% de la salle Tier2 qu'il partage avec CP3 et SIPR, et 50% de la salle Aquarium dont le reste profite aux serveurs de SIPR. Dès leur création, une gestion commune des salles a été mise en place et les systèmes de monitoring et de gestion développés par une des entités est, pour l'essentiel, mis à disposition des autres. De même, la surveillance des pannes et les contacts avec GTPL sont partagés via une liste de diffusion électronique s'adressant sans distinction à tous les gestionnaires de salles.

Lorsque des travaux ou transformations importants s'avèrent nécessaires, l'avis des autres entités est pris en compte afin, si possible, d'en faire bénéficier l'ensemble des utilisateurs des salles.

En 2011, comme mentionné dans notre rapport annuel précédent, SIPR et le CISM ont déposé une demande commune aux autorités de l'Université pour le financement d'une nouvelle salle serveurs. Cette salle doit répondre aux besoins grandissant de nos deux entités et à la fermeture annoncée de la salle Pyth03. Plus de détails sur cette demande sont fournis au paragraphe 3.1.

6.3. La coopération avec la plate-forme Support en Méthodologie et Calcul Statistique (SMCS).


Comme mentionné plus haut, la collaboration structurelle entre le CISM et le SMCS s'est poursuivie cette année encore.
D'une part, le CISM s'occupe de la maintenance matérielle et du système d'exploitation des deux machines de calcul statistique, ainsi que de la gestion des comptes utilisateurs sur ces machines.
D'autre part, le CISM participe au comité de gestion du SMCS, et inversement : une représentation croisée de chacun dans l'organe de décision de l'autre est ainsi en place.


6.4. Projet d'ouverture interuniversitaire des installations de calcul intensif de la Fédération Wallonie Bruxelles.


Depuis sa création en 2008 et la signature de l'accord de collaboration entre les cinq universités de la Fédération Wallonie Bruxelles (FWB) en 2010, le Consortium des Equipements de Calcul Intensif (CÉCI) est à présent largement opérationnel. De nombreux chercheurs partagent les infrastructures mises en place dans les différentes universités membres du Consortium et suivent les formations qui leur sont proposées. Un état d'avancement du projet est présenté plus en détails au chapitre 7.

7. Consortium des Equipements de Calcul Intensif en FWB


En 2013, les infrastructures de calcul du CÉCI - Consortium de Equipements de Calcul Intensif (F.R.S.-FNRS) – se sont renforcées avec l'installation de nouvelles grappes de calcul à l'ULB, UMons et UNamur (inaugurée lors de la réunion du groupe de contact FNRS le 19 avril 2013). Un nouveau cluster est également en cours d'installation à l'ULg au moment d'écrire ces lignes. Cette mise à niveau permet au CÉCI de mettre plus de 7600 coeurs à la disposition de tous les chercheurs membres du Consortium (près de 500 chercheurs).

puissance théorique CECI
Figure 25: Evolution de la puissance théorique de calcul depuis 2008 en tenant compte des installations CÉCI.

Si on regarde l'utilisation de ces machines (Figures 26 et 27), on remarque que dès l'installation de HMEM, le nombre d'utilisateurs actifs à l'UCL (en bleu) est arrivé à son niveau maximum alors que ceux provenant des autres universités du CÉCI (en rouge) continue à augmenter. Le temps calcul suit la même tendance que la puissance disponible. Ce qui montre que les besoins en terme d'infrastructure de calcul restent importants.
utilisateurs actifs
Figure 26: Évolution du nombre d'utilisateurs actifs appartenant à l'UCL (en bleu) et aux autres universités du CÉCI (en rouge).
utilisateurs actifs
Figure 27: Evolution du temps d'utilisation des CPU par les utilisateurs de l'UCL (en bleu) et des autres universités du CÉCI (en rouge).
Pour rappel, grâce au système d'authentification centralisé, mis au point en 2011, les chercheurs ont accès à l'ensemble de ces infrastructures via un identifiant unique.

7.1. Développement de l'outil Slufl

La gestion centralisée des comptes CÉCI passe par un serveur principal auprès duquel les nouveaux comptes sont enregistrés. Ces nouveaux comptes sont propagés par la suite à tous les clusters du CÉCI, où une procédure automatique 'installe' ces nouveaux utilisateurs : création de leur répertoire home, installation de leur clé d'accès, mise en place des quotas, enregistrement dans la base d'utilisateurs du logiciel de gestion de jobs (Slurm), etc. Cette procédure automatique est implémentée par un programme appelé Slufl qui tourne sur les machines de tête de chaque cluster CÉCI.

Ce programme Slufl a été développé au sein du CISM. Il a initialement été créé pour HMEM, et une version plus élaborée a été développée lors de l'installation de LEMAITRE2. Cette version, modulaire, résistante aux erreurs (fault tolerant), et bien sécurisée, a été proprement packagée (package RPM, fichier de configuration, scripts de démarrage/arrêt, etc.) et distribuée aux autres universités membres du CÉCI.

Slufl est actuellement installé et utilisé sur tous les clusters du CÉCI.

Cette année, une nouvelle version a été conçue pour améliorer encore son extensibilité. Cette version compte environ 700 lignes de code Python, basées uniquement sur les librairies de base, et prend en charge, si besoin à distances (à travers SSH), et en mode interactif ou 'daemon', toutes les actions de mise en place des nouveaux comptes utilisateurs.

7.2. Enquête de satisfaction


Cette année, le CISM a organisé une grande enquête de satisfaction auprès des utilisateurs des clusters du CÉCI. Durant le mois de mai, 130 utilisateurs actifs ont été contacté et les questions suivantes leur ont été posées :
  • Comment connaissez-vous le CÉCI ?
  • Quelles difficultés avez-vous rencontré lors de la création de votre compte ?
  • Quels sont vos besoins en matériel, en logiciel ?
  • Quelles sont les caractéristiques d'un job typique ?
Le questionnaire proposait également un champ permettant les commentaires libres. L'enquête était anonyme mais des informations concernant l'institution et le thème de recherche des répondants étaient demandées.

Soixante réponses ont été obtenues, dont un tiers venant de l'UCL. Les réponses nous ont permis de nous conforter dans les choix matériels fait pour les clusters installés à l'UCL, et de nous rendre compte que certaines informations étaient méconnues des utilisateurs. En conséquence, le site web a été enrichi de contenus destinés à mettre en avant ces informations. Une demande précise et récurrente a également été mise en évidence, ce qui a incité l'équipe à organiser une intervention majeure de mise à jour du logiciel de gestion des jobs. Celle-ci a eu lieu en juillet.

Les répondants avaient la possibilité de laisser leurs coordonnées pour être contacté par un gestionnaire directement pour discuter des problèmes rencontrés. Une dizaine de répondants ont profité de cette opportunité et leurs problèmes ont été solutionnés. Par ailleurs, une réponse détaillée à chaque point soulevé anonymement a été rédigée et postée sur le site web.

Un résumé des résultats de l'enquête et la réponse rédigée sont disponibles à l'adresse: http://www.ceci-hpc.be/survey2013.html .

8. 2014 et au delà...


Pour le CISM, les objectifs pour l'année prochaine sont nombreux. On peut d'abord mentionner la finalisation de la réorganisation du fonctionnement de notre plate-forme. Ceci passe par la désignation d'un Institut de référence pour le CISM et la modification de notre ROI. D'autre part, nous devons avancer dans l'aménagement de la nouvelle salle machine, si importante pour l'hébergement de nos infrastructures et celles de IRMP/CP3. Il s'agit donc d'apporter tout notre soutien, avec l'aide de SGSI/SIPR, à GTPL, en charge du projet. Enfin, parmi les différents projets d'amélioration de nos services aux utilisateurs, nous pouvons souligner les efforts entamés avec les informaticiens de IRMP/CP3 pour partager nos ressources. Ce dernier objectif devra prendre une forme plus concrète en 2014 afin de profiter de l'aménagement de la nouvelle salle, prévu mi 2015, pour le mettre à exécution.

Pour le CÉCI, l'année 2013 aura encore été une année importante avec l'installation et la mise en service de nouveaux clusters à Bruxelles, Namur, Mons et Liège. En 2014, les infrastructures du CÉCI sont enfin complètes et il est déjà temps de penser au renouvellement partiel de certaines installations. En effet, en 2015, HMEM et LEMAITRE2 entreront respectivement dans leur cinquième et quatrième année d'utilisation. Leur remplacement est donc à prévoir. D'autres projets doivent également émerger pour améliorer encore l'offre du CÉCI. Le réseau inter-sites pourrait être amélioré et permettre la mise en place d'un système de fichiers partagés regroupant les cinq sites de notre consortium.

Enfin, nous attendons la mise en service du nouveau supercalculateur du Cenaero (niveau Tier-1 PRACE) prévue au mois d'avril ou mai de cette année. Ce supercalculateur, financé par la Région Wallonne, viendra compléter nos infrastructures locales, de type Tier-2 dans la hiérarchie établie par le projet européen PRACE, et permettre à nos utilisateurs de travailler sur plusieurs milliers de coeurs de calcul en parallèle. Ce nouvel outil sera la marche idéale pour préparer l'accès, pour nos utilisateurs, aux clusters européens les plus importants.

Annexe A: veille technologique


A.1. Evaluation de Systèmes de fichiers distribués


Les espaces de stockage devenant de plus en plus volumineux, nécessitant l'accumulation de plusieurs serveurs interconnectés, le besoin d'un système de fichiers distribué, permettant le regroupement de plusieurs serveurs de données en un seul point d'accès, devient de plus en plus important. Et ce, non seulement pour un accès aux données cohérent et transparent pour l'utilisateur, mais également pour en améliorer les performances.

Plus spécifiquement, nous pouvons identifier deux types de besoin sensiblement différents. Le premier concerne nos utilisateurs locaux du stockage de masse. Pour ceux-ci, le système de fichier doit permettre de retrouver l'ensemble de leurs données de manière cohérente, sur un seul point de montage et donc, dans un seul et même volume. Le second type de besoin concerne les utilisateurs du CÉCI, travaillant sur des clusters délocalisés et recherchant l'accès aux mêmes données partagées sur les différents sites. Pour ces derniers, il faut trouver une solution robuste pour le partage des fichiers à travers un réseau étendu.

Parmi les candidats potentiels pour répondre à ces différents besoins, nous avons sélectionné les systèmes de fichiers suivants :
Pour chacun de ces systèmes de fichiers (ou de transfert de fichiers), nous avons évalué trois critères :
Ces tests ont été effectués à l'aide du banc de test « l'élève » que nous avons mis en place pour valider certaines configurations avant leur mise en production.
Figure A1.1: Banc de test Leleve
Comme on peut le voir à la figure A.1.1, notre banc de test est limité à trois serveurs de données ne disposant que de 66 GB d'espace à partager et un quatrième serveur hébergeant les métadonnées et qui sera également utilisé comme client pour l'accès au système de fichier. Le tout est interconnecté par un switch GbE. Malgré cette configuration minimale, nous disposons de tout ce qu'il nous faut pour effectuer nos évaluations.

A.1.1. NFS-FUSE base FS


Ce système de fichier se base sur le montage NFS de plusieurs points de montage ou partitions sur la partie client. Une couche FUSE est alors utilisée sur le client pour rassembler les différents montages NFS en un seul point et permettre l'accès aux fichiers et leur gestion. Le serveur de données n'est donc rien d'autre qu'un serveur NFS.
L'installation est triviale et ne s'opère que sur le client. Elle ne nécessite en effet que la compilation d'un fichier C et l'installation de FUSE dont le package YUM est disponible pour les distributions Red Hat.

La configuration se limite à quelques lignes dans un fichier listant les points de montage à associer, le path pour les métadonnées et celui du point de montage à créer. Il suffit ensuite de démarrer un démon (processus) qui crée le système de fichier et le monte via FUSE.

La simplicité de ce système est son avantage principal. De plus, si le système de fichier s'arrête de fonctionner, les données restent directement accessibles via le montage NFS.

Sa simplicité est également un désavantage. Les montages NFS sont visibles et donc, des précautions doivent être prises pour éviter l'accès direct aux fichiers sans passer par le système de fichier et risquer ainsi de désynchroniser les métadonnées. De plus, il n'y a pas de possibilité de duplication automatique et aucun outil de transfert de données n'existe en dehors du montage FUSE. Enfin, ce système n'est pas destiné à être distribué, ni développé pour d'autres utilisations que celle prévue dans le cadre du projet CP3.

L'utilisation de ce système de fichier est clairement locale et même limitée de préférence au même sous-réseau. Il ne peut donc pas s'appliquer à une structure multi-sites.

A.1.2. XRootD


XrootD a été développé par l'Université de Stanford et le CERN. Il permet de rassembler des répertoires de plusieurs serveurs de données en un seul point de montage. L'accès aux données s'effectue via des outils spécifiques au système de fichier ou via un montage FUSE.

Sous redhat, l'installation de XrootD et FUSE s'effectue via des packages YUM. Des binaires sont également disponibles pour Solaris.

La configuration se limite à deux fichiers identiques sur tous les serveurs de données et sur le serveur de management. Deux démons à démarrer : cmsd pour la communication entre serveurs de données et xrootd pour les échanges avec les clients.

Les avantages de ce système sont multiples. Il est facile à installer et à configurer. Rassemblant des répertoires qui ont leur propre système de fichier, on peut retrouver ses fichiers même en cas de crash du système distribué. On peut monter le système sur les clients via FUSE mais des outils spécifiques et efficaces de transfert existent, sans nécessité de montage. Le système est « fault-tolerant » : la perte d'un serveur de données ne compromet pas l'accès aux autres serveurs. Le système s'adapte aux serveurs disponibles.

Du côté des désavantages, on peut noter l'absence de possibilité de duplication et une documentation peu ou mal organisée. Aussi, sur le système de fichier, tous les fichiers appartiennent à l'utilisateur xrootd. Les droits d'accès sont donc liés à la hiérarchie des répertoires. Ce qui permet aussi à un utilisateur anonyme d'écrire sur le système, situation observée si on utilise la paramétrisation proposée par défaut. Cependant, il est aussi possible de configurer XrootD de telle sorte que les utilisateurs soient authentifiés par Grid Security Infrastructure (GSI), augmentant sensiblement la sécurité de la solution.

Le déploiement du système est plutôt adapté à un seul site mais l’existence d'outils de transfert et la possibilité d'authentifier les utilisateurs par GSI rendent le système adapté au transfert efficace de données d'un site à une autre, à travers le réseau internet.

A.1.3. FHGFS


FHGFS a été développé par Fraunhofer ITWM en Allemagne. C'est une système de fichier parallélisé spécifiquement adapté au calcul haute performance (HPC). Les serveurs de données sont rassemblés en un seul point de montage. Le système est monté directement sur le client pour l'accès aux données.

L'installation est simplifiée sous linux grâce aux packages YUM disponibles pour RedHat. Il n'y a par contre pas de solution pour Solaris et Windows. Il y a quatre services à installer : le management, la gestion des métadonnées, les serveurs de stockage et les clients. Chaque service est associé à un fichier de configuration et un démon à démarrer sur le serveur hébergeant celui-ci.

Assez facile à installer et à configurer. Il permet le « striping » des fichiers, améliorant les performances IO du système. Le système est tolérant à la perte d'un serveur de stockage et des outils de duplication sont en développement pour les versions à venir.

Par contre, il ne propose pas d'outil de transfert. Ce qui impose au client de rester relativement proche des serveurs. Ce n'est pas un système adapté à une gestion multi-cluster. De plus, en cas de crash du système de fichier, les données ne sont pas directement accessibles. Il faut donc s'assurer de la pérennité des données du serveur de metadonnées. Surtout si les fichiers sont « stripés », c.à.d, découpés en paquets distribués sur plusieurs serveurs de stockage.

L'utilisation de ce système de fichier est adapté à la production et à l'écriture efficace de données sur un cluster de calcul.

A.1.4. SECTOR


Sector a été initié en 2006 par le National Center for Data Mining (NCDM). Il permet de rassembler, de manière sécurisée, des serveurs de stockage provenant de plusieurs sites en un seul point d'accès.

Son installation s’effectue via un tarball à télécharger et un makefile à compiler. On peut ajouter une partie FUSE sur les clients si on veut monter le système de fichier. La configuration est relativement aisée si on suit la procédure standard. Trois services à démarrer : Security server (gère la sécurisation du trafic entre les différents serveurs : Master, Slaves et Clients), Master (management) et Slaves (stockage des données).

Les avantages de ce système sont nombreux. Les fichiers restent accessibles directement sur les serveurs de stockage, même en cas de crash du système. Des outils de transfert existent sans devoir monter le système sur les clients. Les communications entre serveurs sont sécurisées via une couche SSL. Le système est tolérant aux pannes des serveurs de stockage (Slaves). Les transferts de données est rendu efficace par l'utilisation du protocole UDP-based Data Transfert Protocol (UDT). Les serveurs de stockage peuvent être distribués sur plusieurs sites. Le système tient compte de la distance entre serveurs (topologie) pour la gestion des duplications éventuelles et l'accès aux données par un client.

Pas vraiment de désavantage à mettre en avant si ce n'est une activité relativement faible dans les forums depuis 2012 et un risque que ce système ne soit pas supporté à long terme. Ce qui reste à vérifier.

A.1.5. Hadoop (HDFS)


Depuis 2009, Hadoop fait partie de la fondation Apache.

Des RPM existent pour l'installation sous redhat. Des solutions existent également pour Windows et Solaris. La configuration s'effectue par l'intermédiaire de 5 fichiers à copier sur tous les serveurs (namenode et datanodes). Un démon est à démarrer en fonction du type de serveur concerné.

Facile à installer et relativement facile à configurer, ce système présente de nombreuses possibilités de duplications. Il ne permet pas de montage direct sur les clients mais propose des outils de transfert efficaces.

Par contre, il ne permet pas d'accès direct aux données qui deviennent inaccessibles en cas de perte du système de fichier.

Son utilisation est prévue pour un cluster et ne semble pas adapté pour le partage et le transfert de données entre deux sites éloignés.

A.1.6. Globus Online (GridFTP)


Globus Online a été développé par le Computation Institute de l'Université de Chicago. Il propose une plateforme permettant le transfert massif et sécurisé de fichiers entre serveurs GridFTP. Il ne s'agit donc pas d'un système de fichier mais d'un outil de transfert inter-sites.

Le site de Globus Online propose des outils simplifiés pour installer et configurer un client sur son poste de travail (sous linux, Windows ou MacOS) ou un serveur Globus Online (GridFTP + MyProxy) sur son cluster local sous linux. Indépendamment de Globus Online, on peut également installer un serveur GridFTP via Globus Toolkit et contrôler intégralement la configuration du serveur. La configuration d'un tel serveur est cependant plus délicate.

Les avantages de cet outil de transfert se retrouvent dans son caractère multi-sites avec une sécurisation efficace des données et un système d'authentification des utilisateurs performant, basé sur le principe GSI.

Il ne s'agit cependant pas d'un système de fichier et le protocole de transfert est un peu plus complexe à utiliser que les outils UNIX standards.

A.1.7. Tableau comparatif


Le tableau suivant présente une comparaison des différents systèmes testés. ll met en comparaison :
Dans ce dernier, on peut observer que seul SECTOR répond à tous les critères. Certains symboles sont notés en orange lorsque la situation n'est pas claire ou à préciser. Par exemple, XrootD et Hadoop ne sont pas optimisés pour le partage de données sur des sites distants mais proposent, par contre, des outils de transfert pouvant être utilisés entre deux localisations distinctes.
La duplication est encore en test sur la version (2012.10) de FHGFS que nous avons testée. Ce symbole devrait donc passer au vert très bientôt. Aussi dans FHGFS, si les fichiers ne sont pas découpés et distribués sur plusieurs serveurs, il est possible de retrouver les données mais ce n'est pas trivial.

FS

FS Mount

Transfert Tools

Fault tolerance

File recovery

Duplication

WAN

NFS-FUSE

✔

✗

✗

✔

✗

✗

XRootD

✔

✔

✔

✔

✗

✔

FHGFS

✔

✗

✔

✗

✔

✗

SECTOR

✔

✔

✔

✔

✔

✔

Hadoop

✗

✔

✔

✗

✔

✔

GridFTP

✗

✔

✗

✔

✗

✔

A.1.8. Performances IO


La figure suivante présente les résultats en écriture de fichiers sur le système de fichier en utilisant les outils de transfert disponibles. NFS-FUSE et FHGFS ne proposant pas ce type d'outil, ne sont pas repris dans ces résultats. De même, XrootD et GridFTP ne proposant pas de duplication, disparaissent des mesures marquées « d2 », pour duplication des fichiers par 2. Les mesures marquées « x3 » représentent le transfert simultané de 3 fichiers de même taille.
Figure A.1.2: Résultats en écriture via les outils de transfert proposés par le système de fichier.
Si SECTOR ne s'en sort pas trop mal, les meilleurs performances sont observées globalement pour XrootD et GridFTP.

La figure suivante présente les résultats en lecture, avec les mêmes conditions d'utilisation. Le comportement des différents systèmes est assez semblable qu'en écriture.
Figure A.1.3: Résultats en lecture via les outils de transfert proposés par le système de fichier.

Dans le figure A.1.4, on retrouve les résultats de transfert en écriture via le montage direct du système de fichier. Hadoop et GridFTP ne permettant pas ce type de montage, ils ne sont pas repris dans ces résultats.
Ici, ce sont NFS-FUSE et FHGFS qui présentent les meilleurs résultats. Dans le test « iozone t3 » , on écrit simultanément sur le système à partir de trois clients différents. C'est la raison pour laquelle cette mesure dépasse les 120 MB/s, limite attendue pour une connexion GbE. Dans ce cas, c'est XrootD qui se comporte le mieux.
Figure A.1.4: Résultats en lecture sur le système de fichier monté directement par le système d'exploitation.
Au vu de ces différents résultats et des points positifs et négatifs que nous avons pu soulever dans cette comparaison, il n'est pas nécessairement évident de trancher et de choisir le système le plus adapté.

Pour le CISM, pour aller au plus simple, avec le peu de serveur de stockage à partager, le système NFS-FUSE pourrait être suffisant. Cependant, si notre infrastructure devait s'étendre encore (facteur 2 ou 3), un système plus adapté devra être envisagé. Le meilleur candidat serait probablement XRootD.

Pour le CECI, SECTOR semble obtenir tous les suffrages. Il semble en tout cas accumuler tous les avantages. Il faudra cependant s'assurer de la pérennité du support des développeurs de ce système avant de nous engager dans cette voie. Une première étape pourrait être de définir des espaces de stockage dans chaque site et d'y installer des serveurs GridFTP pour organiser le transfert des données d'un site à l'autre. Cette question doit encore être débattue entre administrateurs.

A.2. Les accélérateurs hardware


Un accélérateur matériel est un équipement particulier qui peut être ajouté à un ordinateur pour en améliorer les performances. Les accélérateurs ont fait leur apparition dans les gros clusters de calcul en 2010, et la tendance ne fait que s’accroître. Tous les clusters du CÉCI ont ainsi au moins un ou deux noeuds avec un accélérateur matériel.

Le marché des accélérateurs destinés au calcul intensif a longtemps été dominé par nVidia, le fabricants de cartes graphiques, qui dédiait une partie de sa gamme au calcul scientifique : les cartes Tesla. Depuis cette année, Intel, le constructeurs de processeurs, propose également une gamme d'accélérateurs matériels appelés Xeon Phi.

Les cartes Tesla et les cartes Xeon Phi sont de construction similaire : il s'agit de cartes d'extension de type 'PCI' qui viennent se placer dans le châssis d'un ordinateur. Ces cartes possèdent des unités de calcul différentes de celle que l'on trouve dans l'unité centrale d'un ordinateur et une mémoire spécifique. Leurs prix et consommation électrique sont globalement comparables. Cependant, alors que la carte GPU ne peut s'accéder qu'au travers du micrologiciel (driver) de la carte, l'accès à la carte Xeon Phi peut se faire par SSH, comme pour un ordinateur classique. En effet, la carte possède un système d'exploitation embarqué très similaire à celui de la machine dans laquelle elle est installée.
Beaucoup de noms sont couramment utilisés pour désigner l'un ou l'autre de ces accélérateurs, au point de pouvoir semer la confusion dans l'esprit de celui qui s'y intéresse. Ainsi, les noms des produits, des lignes de produit, des projets, des chips, sont parfois utilisés indifféremment. Dans le tableau suivant, les termes les plus utilisés sont repris, avec un exemple de Xeon Phi et un exemple de carte GPU.
Figure A.2.1: Catégories des différents noms liés aux accélérateurs, avec à gauche la famille Xeon Phi et à droite la famille Tesla


Architecture et puissance théorique


L'architecture des unités de calcul équipant les cartes Tesla ou XeonPhi sont dérivées de modèles n'étant pas initialement destiné au calcul intensif ; il s'agit d'un GPU, destiné à l'affichage, pour les cartes Tesla, et du Pentium4, une très vieille architecture de microprocesseur pour le Xeon Phi. Les versions actuelles, cependant, comportent des améliorations spécifiquement destinées au calcul intensif ; d'une part la ré-organisation des différents types de mémoire et des unités d'ordonnancement dans la Tesla et l'ajout d'unités de calcul vectoriel dans le Xeon Phi.

La notion de cœur de calcul est fort différente selon qu'il s'agisse d'un cœur de Tesla, d'un cœur de Xeon Phi, ou d'un cœur de CPU traditionnel. Pour s'en convaincre, il suffit de constater que sur une surface relativement équivalente, la Tesla offre plus de 3000 cœurs, le Xeon Phi offre 60 cœurs, et un processeur traditionnel en offre une grosse dizaine tout au plus.

Xeon E5-2690

Xeon Phi 5110P

Tesla K20X

Nombre de coeurs

8

60

2688

Puissance (Watts)

135

230

230

Bande passante mémoire (GB/s)

80

320

250

Puissance de calcul (DP GFlops)

185

1011

1320

Nombre de transistors par coeur

280Million

80Million

2.5Million

Figure A.2.2: Dessin des puces électroniques pour un processeur classique (haut), un Xeon Phi (gauche) et un Tesla (droite)

La puissance théorique de calcul d'un processeur s'exprime souvent en flops, le nombre d'opérations d'addition, soustraction, ou multiplication en virgule flottante que le processeur est capable de faire par seconde. Ce nombre dépend du nombre de cœurs, de la fréquence à laquelle ces cœurs fonctionnent, et du nombre d'opérations flottantes par tour d'horloge que le cœur est capable de délivrer ('throughput'), qui dépend du nombre d'unités arithmétiques et logiques (ALU) disponibles et de la taille des registres y associés.

Fréquence

Nombre de coeurs

Nombre d'opérations par cycle

Puissance théorique

Xeon Sandy Bridge E5-2690

2.9GHz

8

8

185,5GFlops

Tesla K20X

732MHz

2688 (SP)

896 (DP)

2

3935GFlops (SP)

1311GFlops (DP)

XeonPhi 5510P

1.053GHz

60

16

1011GFlops

Excepté pour les GPU, la puissance théorique en simple précision (SP) est le double de la puissance théorique en double précision (DP). Par ailleurs, dans l'architecture Kepler des cartes K20X, seulement 448 coeurs sont capables d'effectuer des opérations plus complexes que les opération arithmétiques (transcendantales, trigonométriques, etc.), alors les cœurs Intel sont capables d'effectuer toutes les opérations.

Donc en fonction du calcul à effectuer, on peut voir de grosses différences.

Mode d'utilisation


Autant les GPUs que les Xeon Phi peuvent s'utiliser en mode 'offload' ; le processeur principal 'délègue' à l'accélérateur une partie du travail. Le programme écrit doit alors explicitement s'occuper de transférer les données nécessaires vers l'accélérateur, transférer le code nécessaire, puis lancer l'exécution du code, et enfin y récupérer les résultats. Toute cette procédure est souvent 'cachée' dans des librairies de calcul dédiées à ce type de matériel, notamment les librairies d'algèbre linéaire ou de traitement de signal.

Cela étant, les cartes Xeon Phi offrent d'autres modèles d'exécution. La carte Xeon Phi renferme en effet un véritable ordinateur miniature dédié au calcul parallèle. Il n'a pas de disque dur, ni de wifi, mais il possède sa propre mémoire et son propre système d'exploitation. On peut s'y connecter à distances comme on se connecte à une machine classique, et y faire tourner des programmes de calcul. Ces programmes ne doivent pas être écrits spécifiquement pour le Xeon Phi, ils doivent uniquement être compilés spécifiquement pour le Xeon Phi. On appelle ce mode d'exécution le mode 'natif'. Il est également possible, avec les cartes Xeon Phi, de travailler dans un mode incluant ces deux manières de faire, alors appelé mode hybride.

Les programmes écrits pour utiliser un GPU doivent utiliser des outils logiciels spécifiques ; les plus utilisées étant CUDA et OpenCL. Ils offrent un paradigme de programmation spécifique aux cartes GPU et demandent souvent beaucoup de temps et d'expertise pour transformer un programme écrit pour un processeur classique en une version équivalente tournant de manière optimale sur un GPU.

La figure suivante montre le même programme de multiplication de matrice écrit, de manière naïve, pour un processeur traditionnel et pour une carte GPU. On voit que les codes sont relativement similaires ; la triple boucle du code CPU est remplacée par une double boucle et l'utilisation d'une syntaxe particulière <<< ... >>> dans le code équivalent GPU. Ce bout de code fait l'hypothèse que les données ont été copiées depuis l'ordinateur vers le GPU au préalable et n'utilise qu'une petite partie de la puissance disponible.
multiplication matricielle
Figure A.2.3: Code naïf de multiplication matricielle sur le CPU (à gauche) et GPU (à droite)
A contrario, le même programme parallèle écrit pour un processeur classique, avec par exemple les extensions de compilateur OpenMP ou une librairie de calcul distribué MPI, pourra tourner sur une carte Xeon Phi sans (trop de) modification. Mais cela demande d'utiliser le couteux compilateur Intel, alors que les compilateurs pour GPU sont gratuits. La figure suivante montre le même extrait de programme, à gauche pour un CPU traditionnel, à droite pour un Xeon Phi en mode 'offload'. La seule différence est l'utilisation d'instructions particulières destinées à indiquer au compilateur les données à transférer vers le Xeon Phi.
multiplication matricielle
Figure A.2.4: Code naïf de multiplication matricielle sur le CPU (à gauche) et Xeon Phi (à droite)

Domaines d'application


Il est important d'être conscient du fait que les données que l'on veut traiter avec un accélérateur doivent 'voyager' depuis la mémoire de l'ordinateur jusque celle de l'accélérateur, et que ce voyage prend un temps qui est non négligeable au regard du temps calcul.

La conséquence principale est que, tant avec les GPU qu'avec les Xeon Phi, l'intérêt n'est marqué que si le temps de calcul est largement supérieur au temps de transfert. Le rapport entre le nombre de bytes transférés et le nombre d'opération de calcul effectuées doit être le plus petit possible. Ce nombre dépend évidemment de la complexité algorithmique du calcul.

La figure suivante illustre ce fait en montrant le temps nécessaire pour additionner deux matrices, d'une part sur un CPU normal, d'autre par sur un GPU, pour différentes tailles de matrices carrées. Dans cette situation, le nombre d'opérations de calcul est directement proportionnel au nombre de bytes de données transmis et le temps total est toujours dominé par le temps de transfert. Le calcul 'exporté' sur le GPU est donc plus lent que le CPU malgré la puissance théorique intrinsèque plus élevée du GPU.
addition de deux matrices
Figure A.2.5: Temps calcul pour l'addition de deux matrices en fonction de la taille, avec GPU (en vert) et sans (en noir).

La multiplication de deux matrices est d'une complexité supérieure ; le ratio entre le nombre de bytes de données transférés et le nombre d'opérations effectuées est nettement plus petit que pour l'addition. Alors, on voit sur les deux figures suivantes, qu'il existe une taille des données au delà de laquelle l'accélérateur est plus rapide que le processeur principal, et en deçà de laquelle cela reste l'inverse.
multiplication de deux matrices
Figure A.2.6: Temps calcul pour la multiplication de deux matrices en fonction de la taille, avec GPU (vert) et sans (noir).



Stratégies de gestion des transferts


Le temps de transfert étant d'importance cruciale, tant nVidia pour les cartes GPU qu'Intel pour les cartes Xeon Phi proposent des stratégies pour minimiser ce problème.

Pour les cartes GPU, il est possible de faire les transferts de données en parallèle avec le calcul. Ainsi, dans le cas de la multiplication matricielle, le calcul démarre dès qu'une ligne complète d'une matrice et une colonne complète de l'autre ont été transférées. De même, le résultat peut être transféré en continu au fur et à mesure qu'il est calculé.

Pour les Xeon Phi, la stratégie est de supprimer tous les transferts entre la mémoire du CPU et celle du Xeon Phi en faisant tourner l'ensemble du programme sur la carte Xeon Phi. Cette stratégie peut s'avérer payante si tout le programme peut bénéficier du grand nombre de cœurs disponible sur le Xeon Phi. A noter que si une partie du programme est irrémédiablement séquentielle, il est possible de la faire tourner sur le processeur principal alors que le programme s'exécute sur l'accélérateur ; il s'agit du mode 'offload inverse'.

Méthodes d'optimisation


Même si un programme simple prévu pour un processeur normal peut être modifié relativement aisément pour tourner sur un accélérateur, rendre cette version performante peut s'avérer nettement plus compliqué car cela demande de tirer parti au mieux de l'architecture de l'accélérateur. Pour les GPU, cela passe notamment par l'utilisation optimale des différents, et nombreux, niveaux de mémoire.

Pour illustrer cela, il suffit de réécrire le programme de multiplication matricielle sur le GPU de manière à utiliser les 'shared memory'. Le programme triple alors de volume en terme de nombre de lignes de code, mais les performances sont meilleures.
multiplication de deux matrices
Figure A.2.8: Nombre d'opérations par secondes sur un GPU pour la multiplication de deux matrices en fonction de la taille, avec les "shared mémory" (ligne discontinue) et sans (ligne continue).

Sur le Xeon Phi, il est important de valoriser entièrement la puissance des unités de calcul 'VPU' qu'il contient et qui n'existent pas sur les processeurs classiques. Cela nécessite d'écrire le code d'une manière à ce qu'il puisse être 'vectorisé' par le compilateur, c'est à dire mis sous une forme qui permette aux VPU d'effectuer le plus grand nombre d'opérations par cycle (jusqu'à 32!). La figure suivante montre le résultat du code de multiplication matricielle dans lequel on a volontairement empêché le compilateur de vectoriser les calculs.
multiplication de deux matrices
Figure A.2.9: Nombre d'opérations par secondes sur un Xeon Phi pour la multiplication de deux matrices en fonction de la taille, avec les "shared mémory" (ligne discontinue) et sans (ligne continue).

Bibliothèques optimisées


Pour encourager l'utilisation des accélérateurs, les vendeurs ont déployé beaucoup d'efforts pour mettre à disposition des utilisateurs des bibliothèques optimisées dédiée à ces accélérateurs. Il s'agit de CUBLAS pour les GPU et de MKL pour les Xeon Phi.

Ces bibliothèques s'utilisent de la même manière que les bibliothèques classiques BLAS, LAPACK, etc. Dès lors, il est possible de prendre un programme qui se base sur ces bibliothèques, et d'y remplacer les bibliothèques initialement prévues par leur équivalent destiné aux accélérateurs.

La figure suivante montre les performances (l'inverse du temps calcul) de la multiplication matricielle de deux matrices carrées dans octave, un logiciel de calcul scientifique, dans lequel les appels aux bibliothèques optimisées ont été remplacés par des appels aux bibliothèques dédiées aux accélérateurs. Cela peut se faire uniquement en modifiant le processus de compilation, et sans toucher au code du programme lui-même.
multiplication de deux matrices
Figure A.2.10: Nombre d'opérations par secondes sur un Xeon Phi pour la multiplication de deux matrices avec Octaves en utilisant les bibliothèques optimisées pour GPU (cublas) et Xeon Phi (MKL).

Conclusions


Tous les accélérateurs ont des puissances importantes et comparables à un même niveau de prix, mais une programmation calquée sur celle des CPU ne permet pas d'en tirer parti ; il faut repenser le code pour mobiliser au maximum les ressources qui y sont disponibles. Cela demande du temps et de l'expertise.

Heureusement, les vendeurs de cartes accélératrices développent des outils logiciels pour aider le programmeur ; et proposent même des librairies optimisées similaires à celles qui sont disponibles pour les processeurs classiques, ce qui fait que dans certains cas, utiliser un accélérateur peut être aussi simple que re-compiler un programme avec d'autres options.

Cela étant, les transferts de données entre la mémoire principale et la mémoire de l'accélérateur sont le point d'achoppement principal. Même si l'accélérateur est plus puissant que le processeur central, si le temps nécessaire au transfert des données est trop important, il est parfois plus avantageux de travailler uniquement sur le processeur principal.

Le point fort du Xeon Phi est que sa programmation est plus proche de celle d'un processeur classique. Le point fort du GPU est qu'il est plus accessible financièrement ; le compilateur est gratuit et la gamme de produit est plus étendue. Un second point fort du GPU est la grande quantité de bibliothèques déjà disponibles pour le calcul scientifique.

Annexe B: Tableau récapitulatif des différents serveurs de calcul.


En 2013, avec l'ajout des partitions OBAN et INDUS à MANNEBACK, compensant largement la réduction de GREEN, l'offre en puissance théorique du CISM a augmenté de 26 %: de 31,4 Tflops, celle-ci est passée à 39,7 Tflops. Le CISM gère un total de 4 grappes de calcul, disposant ensemble de 3860 coeurs, de 15160 GB de RAM et de 249 TB d'espace disque, offrant une puissance théorique maximale d'un peu plus de 39,7 Tflops.


Type
# noeuds
# core / noeud
# core
GFlops tot (peak)
RAM/ noeud (GB)
Espace disque

architecture
Mise en service

Grappe GREEN (NAPS)

GREEN

Front-end
1
8
8
80
32
273GB (/fast)
Dell PowerEdge 1950
09/08

storage01

Fileserver
1
8
8
80
64
11TB (/home)
Dell PowerEdge 1950
09/08

GREEN

Working nodes
96
8
768
7680
38 à 16
, 58 à 32
48GB *96 ( /scratch)
Dual Quad-Core Xeon L5420/ 2.5GHz in Dell Blade M1000e
09/08

Node 097 to 102

(déclassés 07/13)
6
8
48
480
16



Dell PowerEdge 1950
09/08 -> 07/13

Grappe MANNEBACK

MANNEBACK Front-end
1
16
16
256
64
19TB

(/home) + 2.5TB (/workdir)
2x8 core Intel E5-2660 2.2GHz
01/13




mback07

1

8

8

85.4 
(GPU: 78)

24

1TB
  1 SuperMicro 2 Quad-Core Intel Xeon X5550/ 2.67GHz

02/10

mback
07/12


mback08-19

(ELIC)
12
8
96
872
24
16TB
12 HP Proliant 2 Quad-Core Intel Xeon L5520/ 2.27GHz
10/09

mback
07/12


mback20-35
16
8
128
1280
16
3TB

(/scratch)
16 HP Blade Dual Quad-Core Xeon L5420/ 2.5GHz
01/10

mback 07/12

mback40
1
16
16
256
(GPU 2x666, XP 1200)
64
120GB (sda)
Xeon E5-2650
+2 nVidia M2090 + 1 Xeon Phi 5110P
01/13

mback101-121

(INDUS NAPS)
21
16
336
5376
64
500GB (/scratch)
Xeon E5-2650 2GHz
07/13

mback151-156

(OBAN NAPS)
6
32
192
1766
128
500GB (/scratch)
AMD Opt 6276/2.3 GHz
09/13

mback158-159

(OBAN NAPS)
2
32
64
1024
256
500GB (/scratch)
Xeon E5-4640/2.4GHz
09/13

Grappe HMEM

HMEM Frontend
1
12
12
125
64
11TB
1 Dell PE R515 2 AMD Opteron 4180/2.6GHz
12/10

HMEM 01-16

working nodes
16
48
768
6758
2 à 512

7 à 256

7 à 128
26TB
14 Dell PE R815 4 AMD Opteron 6174/2.2GHz
12/10

HMEM17 (ELIC)
1
48
48
422
128
800
1 HP DL585 4 AMD Opteron 6174/2.2GHz
02/11






HMEM18-20 (NAPS)
3
8
24
144
128
1TB
3 Transtec Calleo530 4 Dual Core AMD Opteron 8222SE/ 3GHz
10/08

HMEM
01/12

Grappe LEMAITRE2

LEMAITRE2 Frontend
2
12
24
243
64
27TB
2 HP DL380 2 Xeon X5649 / 2.53GHz
01/12

LEMAITRE2

working node
112
12
1344
13601
48
120TB
112 HP DL380 2 Xeon X5649 / 2.53GHz
01/12

LmPp001-003
3
12
36
364
48
500GB

(sda)
2 HP DL380 2 Xeon X5649 / 2.53GHz

+ nVidia Q4000
01/12

Serveurs spécifiques

Lm9 (INMA)
1
12
12
141
144
8TB
1 HP DL180 2 Intel(R) Xeon(R) CPU X5670/ 2.93GHz
01/11

SMCS1- SMCS2

(SMCS)
2
12
24
295 (+GPU2090)
96
1,8TB
2 HP DL170e 2 Intel(R) Xeon(R) CPU X5675/ 3.07GHz
10/11



Annexe C: tableau récapitulatif des différents serveurs de stockage de masse.

Le CISM offre un espace de stockage en ligne de 310TB, réparti principalement sur 4 serveurs:  storage02, storage03, storage04 et storage05.


Nom

type de serveur

type de stockage

Espace (GB)

Mis en service
Storage02 SUN Galaxy X4540 2 Quad core AMD Opteron 2.3GHz 32GB RAM
 48 SATA 1TB, 36TB net
 36TB (/storage) 12/08
Storage03 Transtec Calleà 344 2 Quad-core Xeon E5506@2.13GHz 24GB RAM
 30 SATA 2TB, 2 SSD 64GB (cache zfs), 42TB net
 42TB (/storage)
 05/10
Storage04
 Supermicro CSE-847E16-R1400UB Six-core Xeon E5645@2.4 GHz 36GB RAM
 34 SATA 3TB, 72TB net
 64TB (/storage)
 05/11
Storage05
 Supermicro CSE-847E16-R1400UB Six-core Xeon E5645@2.4 GHz 36GB RAM
 34 SATA 3TB, 72TB net

 64TB (/storint)
+90TB (/storext)
 05/11

07/12

Annexe D: Publications de résultats ayant été obtenus grâce aux machines du calcul intensif.

Les publications peuvent être consultées en ligne sur le site Dial.pr ou depuis notre  base de donnée.


Journal Articles


1. Robiette, Raphaël; Pospíšil, J. On the Origin of E/Z Selectivity in the Modified Julia Olefination - Importance of the Elimination Step. In: European Journal of Organic Chemistry, Vol. 2013, no.5, p. 836-840 (2013). doi:10.1002/ejoc.201201634. http://hdl.handle.net/2078.1/124571

2. Poncé, Samuel; Bertrand, Bruno; Smet , P.F.; Poelman, D.; Mikami, M.; Gonze, Xavier. First-principles and experimental characterization of the electronic and optical properties of CaS and CaO. In: Optical Materials, Vol. 35, p. 1477-1480 (2013). doi:10.1016/j.optmat.2013.03.001. http://hdl.handle.net/2078.1/127716

3. Da Pieve, F.; Di Matteo, S.; Rangel, T.; Giantomassi, M.; Lamoen, D.; Rignanese, G.-M.; Gonze, X. Origin of Magnetism and Quasiparticles Properties in Cr-Doped TiO_{2}. In: Physical Review Letters, Vol. 110, no.13, p. 136402 (2013). doi:10.1103/PhysRevLett.110.136402. http://hdl.handle.net/2078.1/128665

4. Jain, Anubhav; Ong, Shyue Ping; Hautier, Geoffroy; Chen, Wei; William Davidson Richards; Stephen Dacek; Shreyas Cholia; Dan Gunter; David Skinner; Gerbrand Ceder; Kristin A. Persson. Commentary: The Materials Project: A materials genome approach to accelerating materials innovation. In: APL Materials, Vol. 1, no.1, p. 011002-1 (July 2013). doi:10.1063/1.4812323. http://hdl.handle.net/2078.1/132962

5. Xiaohua Ma; Hautier, Geoffroy; Anubhav Jain,; Robert Doe; Gerbrand Ceder. Improved Capacity Retention for LiVO2 by Cr Substitution. In: Journal of the Electrochemical Society, Vol. 160, no.2, p. A279-A284 (2013). doi:10.1149/2.046302jes. http://hdl.handle.net/2078.1/132982

6. Vincent L. Chevrier; Hautier, Geoffroy; Shyue Ping Ong; Robert E. Doe; Gerbrand Ceder. First-principles study of iron oxyfluorides and lithiation of FeOF. In: Physical review. B, Condensed matter and materials physics, Vol. 87, p. 094118 1-9 (2013). doi:10.1103/PhysRevB.87.094118. http://hdl.handle.net/2078.1/132976

7. Shyue Ping Ong; William Davidson Richards; Anubhav Jain; Hautier, Geoffroy; Michael Kocher; Shreyas Cholia; Dan Gunter; Vincent L. Chevrier; Kristin A. Persson; Gerbrand Ceder. Python Materials Genomics (pymatgen): A robust, open-source python library for materials analysis. In: Computational Materials Science, Vol. 68, p. 314–319 (2013). doi:10.1016/j.commatsci.2012.10.028. http://hdl.handle.net/2078.1/132987

8. Anubhav Jain; Ivano E. Castelli; Hautier, Geoffroy; David H. Bailey; Karsten W. Jacobsen. Performance of genetic algorithms in search for water splitting perovskites. In: Journal of Materials Science, Vol. 48, no. 19, p. 6519-6534 (2013). doi:10.1007/s10853-013-7448-9. http://hdl.handle.net/2078.1/132986

9. Hailong Chen; Qing Hao; Olivera Zivkovic; Hautier, Geoffroy; Lin-Shu Du; Yuanzhi Tang; Yan-Yan Hu; Xiaohua Ma; Clare P. Grey; Gerbrand Ceder. Sidorenkite (Na3MnPO4CO3): A New Intercalation Cathode Material for Na-Ion Batteries. In: Chemistry of Materials, Vol. 25, no. 14, p. 2777–2786 (2013). doi:10.1021/cm400805q. http://hdl.handle.net/2078.1/132990

10. Hautier, Geoffroy; Anubhav Jain; Tim Mueller; Charles Moore; Shyue Ping Ong; Gerbrand Ceder. Designing Multielectron Lithium-Ion Phosphate Cathodes by Mixing Transition Metals. In: Chemistry and Materials Research, Vol. 25, no. 10, p. 2064–2074 (2013). doi:10.1021/cm400199j. http://hdl.handle.net/2078.1/132967

11. Yabi Wu; Predrag Lazic; Hautier, Geoffroy; Kristin Persson; Gerbrand Ceder. First principles high throughput screening of oxynitrides for water-splitting photocatalysts. In: Energy & Environmental Science, Vol. 2013, no. 6, p. 157-168 (2013). doi:10.1039/c2ee23482c. http://hdl.handle.net/2078.1/132970

12. Vergote, Thomas; Nahra, Fady; Peeters, Daniel; Riant, Olivier; Leyssens, Tom. NHC-copper(I) bifluoride complexes: "Auto-activating" catalysts. In: Journal of Organometallic Chemistry, Vol. 730, no. --, p. 95-103 (2013). doi:10.1016/jorganchem.2012.10.011. http://hdl.handle.net/2078.1/119007

13. Frank, Béatrice; Baret, Philippe. Simulating brown trout demogenetics in a river/nursery brook system: The individual-based model DemGenTrout. In: Ecological Modelling, Vol. 248, p. 184-202 (2013). doi:10.1016/j.ecolmodel.2012.09.017. http://hdl.handle.net/2078.1/116943

14. Yin, Qiuzhen. Insolation-induced mid-Brunhes transition in Southern Ocean ventilation and deep-ocean temperature. In: Nature, Vol. 494, p. 222-225 (2013). doi:10.1038/nature11790. http://hdl.handle.net/2078.1/122508

15. Pham Thanh Trung; Joucken, Frédéric; Campos Delgado, Jessica; Raskin, Jean-Pierre; Hackens, Benoît. Direct growth of graphitic carbon on Si(111). In: Applied Physics Letters, Vol. 102, p. 013118 1-5 (2013). doi:10.1063/1.4773989. http://hdl.handle.net/2078/120913

16. Villemin, Elise; Robeyns, Koen; Robiette, Raphaël; Herent, Marie-France; Marchand-Brynaert, Jacqueline. Polycyclic phosphonic acid derivatives obtained by a [4+2] cycloaddition strategy using phosphonodienes. In: Tetrahedron, Vol. 69, no. 3, p. 1138-1147 (2013). doi:10.1016/j.tet.2012.11.059. http://hdl.handle.net/2078/123953

17. Nikolova, Irina; Yin, Qiuzhen; Berger, André; Singh, Umesh Kumar; Karami, Pasha. The last interglacial (Eemian) climate simulated by LOVECLIM and CCSM3. In: Climate of the Past, Vol. 9, no.0, p. 1789–1806 (2013). doi:10.5194/cp-9-1789-2013. http://hdl.handle.net/2078.1/135499

18. Bertrand, Bruno; Poncé, Samuel; Waroquiers, David; Stankovski, Martin; Giantomassi, Matteo; Mikami, M.; Gonze, Xavier. Quasiparticle electronic structure of barium-silicon oxynitrides for white-LED application. In: Physical Review B, Vol. 88, no.7, p. 075136 1-10 (2013). doi:10.1103/PhysRevB.88.075136. http://hdl.handle.net/2078.1/134379

19. Gillet, Yannick; Giantomassi, Matteo; Gonze, Xavier. First-principles study of excitonic effects in Raman intensities. In: Physical review. B, Condensed matter and materials physics, Vol. 88, no.9, p. 094305/1-9 (17 September 2013). doi:10.1103/PhysRevB.88.094305. http://hdl.handle.net/2078.1/135677

20. Champagne, Benoît; Deleuze, Michaël S.; De Proft, Frank; Leyssens, Tom. Theoretical chemistry in Belgium. In: Theoretical Chemistry Accounts, Vol. 132, no.7, p. 1-13 (2013). doi:10.1007/s00214-013-1372-6 (Accepté/Sous presse). http://hdl.handle.net/2078.1/129956

21. Vergote, Thomas; Gharbi, Sonia; Billard, François; Riant, Olivier; Leyssens, Tom. Ketone hydrosilylation by Cu(I) diphosphine complexes: A kinetic study. In: Journal of Organometallic Chemistry, Vol. 745-746, p. 133-139 (2013). doi:10.1016/j.jorganchem.2013.07.054. http://hdl.handle.net/2078.1/134626

22. Da Pieve, Fabiana; Hogan, C.; Lamoen, D.; Verbeeck, J.; Vanmeert, F.; Radepont, M.; Cotte, M.; Janssens, K.; Gonze, Xavier; Van Tendeloo, G. Casting Light on the Darkening of Colors in Historical Paintings. In: Physical Review Letters, Vol. 111, p. 208302 1-5 (2013). doi:10.1103/PhysRevLett.111.208302. http://hdl.handle.net/2078.1/136695

23. Rodrigues Martins, Frederico; Faniel, Sébastien; Rosenow, B.; Sellier, H.; Huant, S.; Pala, M.G.; Desplanque, L.; Wallart, X.; Bayot, Vincent; Hackens, Benoît. Coherent tunnelling across a quantum point contact in the quantum Hall regime. In: Scientific Reports, Vol. 3, no. 1416, p. 1416 (2013). doi:10.1038/srep01416. http://hdl.handle.net/2078.1/128553

24. Gourgue, Olivier; Baeyens, Willy; Chen, Margaret; Debrauwere, Anouk; de Brye, Benjamin; Deleersnijder, Eric; Elskens, Marc; Legat, Vincent. A depth-averaged two-dimensional sediment transport model for environmental studies in the Scheldt Estuary and tidal river network. In: Journal of Marine Systems, Vol. 128, p. 27-39 (2013). doi:10.1016/j.jmarsys.2013.03.014 (Accepté/Sous presse). http://hdl.handle.net/2078.1/127007

25. Muri, Helene; Berger, André; Yin, Qiuzhen; karami, Pasha; Barriat, Pierre-Yves. The climate of the MIS-13 interglacial according to HadCM3. In: Journal of Climate, Vol. 26, no.23, p. 9696–9712 (July 11, 2013). doi:10.1175/JCLI-D-12-00520.1. http://hdl.handle.net/2078.1/136206

26. Hautier, Geoffroy; Miglio, Anna; Ceder, Gerbrand; Rignanese, Gian-Marco; Gonze, Xavier. Identification and design principles of low hole effective mass p-type transparent conducting oxides. In: Nature Communications, Vol. 4, p. 2292 (2013). doi:10.1038/ncomms3292. http://hdl.handle.net/2078.1/132912

27. Rodrigues Martins, Frederico; Faniel, Sébastien; Rosenow, B.; Pala, M.G.; Sellier, H.; Huant, S.; Desplanque, L.; Wallart, X.; Bayot, Vincent; Hackens, Benoît. Scanning gate spectroscopy of transport across aquantum Hall nano-island. In: New Journal of Physics, Vol. 15, p. 013049 10p. (2013). doi:10.1088/1367-2630/15/1/013049. http://hdl.handle.net/2078/123833

28. Adami, O.-A.; Cerbu, D.; Cabosart, Damien; Motta, M.; Cuppens, J.; Ortiz, W.A.; Moshchalkov, V.V.; Hackens, Benoît; Delamare, Romain; Van de Vondel, J.; Silhanek, A.V. Current crowding effects in superconducting corner-shaped Al microstrips. In: Applied Physics Letters, Vol. 102, no. 5, p. 052603 1-4 (2013). doi:10.1063/1.4790625. http://hdl.handle.net/2078/123836

29. Zunz, Violette; Goosse, Hugues; Massonnet, François. How does internal variability influence the ability of CMIP5 models to reproduce the recent trend in Southern Ocean sea ice extent?. In: The Cryosphere, Vol. 7, p. 451-468 (2013). doi:10.5194/tc-7-451-2013. http://hdl.handle.net/2078.1/126087

30. Czerwinski, Bartlomiej Piotr; Delcorte, Arnaud. Molecular dynamics study of fullerite cross-linking under keV C 60 and Arn cluster bombardment. In: The Journal of Physical Chemistry Part C: Nanomaterials and Interfaces, Vol. 117, no.7, p. 3595-3604 (2013). doi:10.1021/jp310635g. http://hdl.handle.net/2078.1/125971

31. Reckinger, Nicolas; Felten, Alexandre; Nascimento Santos, Cristiane; Hackens, Benoît; Colomer, Jean-François. The influence of residual oxidizing impurities on the synthesis of graphene by atmospheric pressure chemical vapor deposition. In: Carbon Materials : chemistry and physics, Vol. 63, p. 84-91 (June 24, 2013). doi:10.1016/j.carbon.2013.06.042. http://hdl.handle.net/2078.1/132948

32. Yerra, S.K.; Martin, G.; Véron, M.; Bréchet, Y.; Mithieux, J.D.; Delannay, Laurent; Pardoen, Thomas. Ductile fracture initiated by interface nucleation in two-phase elastoplastic systems. In: Engineering Fracture Mechanics, Vol. 102, p. 77-100 (2013). doi:10.1016/j.engfracmech.2013.02.028. http://hdl.handle.net/2078.1/128865

33. Wolanski, Eric; Lambrechts, Jonathan; Thomas, Christopher; Deleersnijder, Eric. The net water circulation through Torres Strait. In: Continental Shelf Research, Vol. 64, p. 66-74 (2013). doi:10.1016/j.csr.2013.05.013. http://hdl.handle.net/2078.1/130742

34. Massonnet, François; Mathiot, P.; Fichefet, Thierry; Goosse, Hugues; König Beatty, C.; Vancoppenolle, M.; Lavergne, T. A model reconstruction of the Antarctic sea ice thickness and volume changes over 1980-2008 using data assimilation. In: Ocean Modelling, Vol. 64, p. 67-75 (2013). doi:10.1016/j.ocemod.2013.01.003. http://hdl.handle.net/2078.1/129275

35. Eby, M.; Crespin, Elisabeth; Fichefet, Thierry; Goosse, Hugues. Historical and idealized climate model experiments : An EMIC intercomparison. In: Climate of the Past, Vol. 9, p. 1111–1140 (2013). doi:10.5194/cp-9-1111-2013. http://hdl.handle.net/2078.1/129278

36. Dufresne, J.-L.; Foujols, M.-A.; Fichefet, Thierry. Climate change projections using the IPSL-CM5 Earth System Model: From CMIP3 to CMIP5. In: Climate Dynamics, Vol. 40, no.9-10, p. 2123-2165 (2013). doi:10.1007/s00382-012-1636-1. http://hdl.handle.net/2078.1/129282

37. Bautista-Hernández, A.; Rangel, T.; Romero, A. H.; Rignanese, Gian-Marco; Salazar-Villanueva, M.; Chigo-Anota, E. Structural and vibrational stability of M and Z phases of silicon and germanium from first principles. In: Journal of Applied Physics, Vol. 113, no. 19, p. 193504 (2013). doi:10.1063/1.4804668. http://hdl.handle.net/2078.1/130532

38. Espejo, C.; Rangel, T.; Romero, A. H.; Gonze, Xavier; Rignanese, Gian-Marco. Band structure tunability in MoS2 under interlayer compression: A DFT and GW study. In: Physical Review B, Vol. 87, no.24, p. 245114 (6/17). doi:10.1103/PhysRevB.87.245114. http://hdl.handle.net/2078.1/130284

39. Ahmed, Moinuddin; Anchukaitis, Kevin J.; Asrat, Asfawossen; Borgaonkar, Hemant P.; Braida, Martina; Buckley, Brendan M.; Büntgen, Ulf; Chase, Brian M.; Christie, Duncan A.; Cook, Edward R.; Curran, Mark A. J.; Diaz, Henry F.; Esper, Jan; Fan, Ze-Xin; Gaire, Narayan P.; Ge, Quansheng; Gergis, Joëlle; González-Rouco, J Fidel; Goosse, Hugues; Grab, Stefan W.; Graham, Nicholas; Graham, Rochelle; Grosjean, Martin; Hanhijärvi, Sami T.; Kaufman, Darrell S.; Kiefer, Thorsten; Kimura, Katsuhiko; Korhola, Atte A.; Krusic, Paul J.; Lara, Antonio; Lézine, Anne-Marie; Ljungqvist, Fredrik C.; Lorrey, Andrew M.; Luterbacher, Jürg; Masson-Delmotte, Valérie; McCarroll, Danny; McConnell, Joseph R.; McKay, Nicholas P.; Morales, Mariano S.; Moy, Andrew D.; Mulvaney, Robert; Mundo, Ignacio A.; Nakatsuka, Takeshi; Nash, David J.; Neukom, Raphael; Nicholson, Sharon E.; Oerter, Hans; Palmer, Jonathan G.; Phipps, Steven J.; Prieto, Maria R.; Rivera, Andres; Sano, Masaki; Severi, Mirko; Shanahan, Timothy M.; Shao, Xuemei; Shi, Feng; Sigl, Michael; Smerdon, Jason E.; Solomina, Olga N.; Steig, Eric J.; Stenni, Barbara; Thamban, Meloth; Trouet, Valerie; Turney, Chris S.M.; Umer, Mohammed; van Ommen, Tas; Verschuren, Dirk; Viau, Andre E.; Villalba, Ricardo; Vinther, Bo M.; von Gunten, Lucien; Wagner, Sebastian; Wahl, Eugene R.; Wanner, Heinz; Werner, Johannes P.; White, James W.C.; Yasue, Koh; Zorita, Eduardo. Continental-scale temperature variability during the past two millennia. In: Nature Geoscience, Vol. 6, no.5, p. 339-346 (2013). doi:10.1038/NGEO1797. http://hdl.handle.net/2078.1/129627

40. Goosse, Hugues; Roche, D.M.; Mairesse, Aurélien; Berger, M. Modelling past sea ice changes. In: Quaternary Science Reviews, , no.n/, p. 1-16 (2013). http://hdl.handle.net/2078.1/129633

41. Crespin, Elisabeth; Goosse, Hugues; Fichefet, Thierry; Mairesse, Aurélien; Sallaz-Damaz, Yoann. Arctic climate over the past millennium: Annual and seasonal responses to external forcings. In: The Holocene, Vol. 23, no. 3, p. 321-329 (2013). doi:10.1177/0959683612463095. http://hdl.handle.net/2078.1/119079

42. Mathiot, Pierre; Goosse, Hugues; Crosta, Xavier; Stenni, Barbara; Braida, Martina; Renssen, Hans; Van Meerbeeck, Cédric J.; Masson-Delmotte, Valérie; Mairesse, Aurélien; Dubinkina, Svetlana. Using data assimilation to investigate the causes of Southern Hemisphere high latitude cooling from 10 to 8 ka BP. In: Climate of the Past, Vol. 9, no.2, p. 887-901 (2013). doi:10.5194/cp-9-887-2013. http://hdl.handle.net/2078/127079

43. Mairesse, Aurélien; Goosse, Hugues; Mathiot, P.; Wanner, H.; Dubinkina, Svetlana. Investigating the consistency between proxy-based reconstructions and climate models using data assimilation: a mid-Holocene case study. In: Climate of the Past, Vol. 9, no.6, p. 2741-2757 (2013). doi:10.5194/cp-9-2741-2013. http://hdl.handle.net/2078.1/135772

44. De Vernal, A.; Gersonde, R.; Goosse, Hugues; Seidenkrantz, M.-S.; Wolff, E.W. Sea ice in the paleoclimate system: The challenge of reconstructing sea ice from proxies - an introduction. In: Quaternary Science Reviews, Vol. 79, p. 1-8 (2013). doi:10.1016/j.quascirev.2013.08.009. http://hdl.handle.net/2078.1/135231

45. Fichefet, Thierry; lecomte, Olivier; Vancoppenolle, Martin; Massonnet, François; Barriat, Pierre-Yves. On the formulation of snow thermal conductivity in large-scale sea ice models. In: Journal of Advances in Modeling Earth Systems, Vol. 5, p. 542-557 (2013). doi:10.1002/jame.20039, 2013. http://hdl.handle.net/2078.1/135798

46. Bouillon, Sylvain; Fichefet, Thierry; Legat, Vincent; Madec, Gurvan. The elastic–viscous–plastic method revisited. In: Ocean Modelling, Vol. 71, p. 2-12 (2013). doi:10.1016/j.ocemod.2013.05.013. http://hdl.handle.net/2078.1/135796

47. Tetchou Nganso, H.M.; Hamido, A.; Kwato Njock, M.G.; Popov, Y.V.; Piraux, B. Interaction of a model atom exposed to strong laser pulses: Role of the Coulomb potential. In: Physical Review A - Atomic, Molecular, and Optical Physics, Vol. 87, no.1, p. art 013420 (2013). doi:10.1103/PhysRevA.87.013420. http://hdl.handle.net/2078/124766

48. Correa Da Rocha, Luis Enrique; Blondel, Vincent. Flow motifs reveal limitations of the static framework to represent human interactions. In: Physical Review, Vol. 87, no. 4, p. 042814-1 (9 pages) (April 2013). doi:10.1103/PhysRevE.87.042814. http://hdl.handle.net/2078.1/128468

49. Correa Da Rocha, Luis Enrique; Blondel, Vincent. Bursts of vertex activation and epidemics in evolving networks. In: PLoS Computational Biology, Vol. 9, no. 3, p. e1002974 (2013). doi:10.1371/journal.pcbi.1002974. http://hdl.handle.net/2078.1/124321

50. Marie-Caroline Jonville, Georges Dive, Luc Angenot, Joanne Bero, Monique Tits, Evelyne Ollivier, Michel Frédérich
``Dimeric bisindole alkaloids from the stem bark of Strychnos nux-vomica L.''
Phytochemistry 87, pp 157-163 (2013). http://hdl.handle.net/10.1016/j.phytochem.2012.11.002 Contact:GDive@ULg.ac.be

51. Georges Dive, Camille Bouillon, Aline Sliwa, Bénédicte Valet, Olivier Verlaine, Eric Sauvage, Jacqueline Marchand-Bryanert
``Macrocycle-embedded b-lactams as novel inhibitors of the Penicillin Binding Protein PBP2a frpm MRSA''
Eur. J. Med. Chem. 64, pp 365-376 (2013). http://hdl.handle.net/10.1016/j.ejmech.2013.03.052 
Contact:GDive@ULg.ac.be

52. Jean-Christophe Monbaliu, Georges Dive, Christian Stevens, Alan Katritzky
``Governing parameters of long-range intramolecular S-to-N acyl transfers within (S)-acyl isopeptides''
J. Chem. Theory Comput. 9, pp 927-934 (2013).
http://hdl.handle.net/10.1021/ct300830k Contact:GDive@ULg.ac.be

53. A. Patterson, A. Ghysselinckx et al
``NetQues Project Report Speech and Language Therapy Education in Europe United in Diversity''
Project No. 177075-LLP-1-2010-1-FR-ERASMUSENWA , pp 1-114 (2013).
Contact:anne.ghysselinckx@uclouvain.be

54. Hogenraad, R. L., Garagozov, R. R.
``Textual fingerprints of risk of war''
Literary and Linguistic Computing http://hdl.handle.net/10.1093/llc/fqt015, pp - (2013).
Contact:robert.hogenraad@uclouvain.be

Conference Papers


1. Roelofs, F.; Rohde, M.; Otic, I.; Brillant, G.; Tiselj, I.; Anglart, H.; Niceno, B.; Duponcheel, Matthieu; Stalio, E.; Ambrosini, W.; Lakehal, D.; Baglietto, E.. European Developments in SIngle Phase Turbulence for Innovative Reactors. Nureth 15 (Pisa, Italia, du 12/05/2013 au 17/05/2013). http://hdl.handle.net/2078.1/130140

2. Hautier, Geoffroy. Accelerating materials discovery through high-throughput computing and the Materials Project. Special Seminar at Unicat (German cluster of excellence in catalysis) (Berlin, Germany). http://hdl.handle.net/2078.1/133875

3. Hautier, Geoffroy. Accelerating materials discovery for industrial applications using highthroughput ab initio computing. European Theoretical Spectroscopy Facility (ETSF) Young researchers’ meeting (Budapest (Hungary)). http://hdl.handle.net/2078.1/134979

4. Hautier, Geoffroy. Data Mined Compound and Crystal Structure Prediction for High-Throughput Materials Discovery. Society for Industrial and Applied Mathematics (SIAM) conference (Philadelphia, USA). http://hdl.handle.net/2078.1/134978

5. Hautier, Geoffroy. A High-Throughput Computational Search for New p-type Transparent Conducting Oxides. Workshop on The future of transparent conducting oxides (Hasselt (Belgium). http://hdl.handle.net/2078.1/134977

6. Hautier, Geoffroy. A new Klondike for materials?. The Materials Project, Materials Evolution workshop (Lund (Sweden)). http://hdl.handle.net/2078.1/134976

7. Rodrigues Martins, Frederico; Faniel, Sébastien; Rosenow, B.; Sellier, H.; Huant, S.; Pala, M.; Desplanque, L.; Wallart, X.; Bayot, Vincent; Hackens, Benoît. Coherence and Coulomb Blockade in Ultra-Small Quantum Hall Islands. Le Forum des microscopies à sonde locale (Spa, Belgium). http://hdl.handle.net/2078.1/135315

8. Rodrigues Martins, Frederico; Faniel, Sébastien; Hackens, Benoît. Imaging transport inside a quantum ring. hosted by Prof. Takaaki Koga, Hokkaido University (Japan). http://hdl.handle.net/2078.1/135323

9. Rodrigues Martins, Frederico; Faniel, Sébastien; Hackens, Benoît. Imaging transport inside a quantum ring. hosted by Prof. Minoru Kawamura (Riken, Japan). http://hdl.handle.net/2078.1/135320

10. Rodrigues Martins, Frederico; Faniel, Sébastien; Hackens, Benoît. Imaging transport inside a quantum ring. hosted by Dr. Muraki, NTT Basic Research Laboratories (Japan). http://hdl.handle.net/2078.1/135322

11. Hautier, Geoffroy; Miglio, Anna; Rignanese, Gian-Marco; Ceder, G.; Gonze, Xavier. How to design low hole effective mass p-type transparent conducting oxides? A high-throughput computational analysis. MRS Spring Meeting (San Francisco, USA). http://hdl.handle.net/2078.1/135425

12. Sellier, H.; Pala, M.; Baltazar, S.; Liu, P.; Hackens, Benoît; Rodrigues Martins, Frederico; Wallart, X.; Desplanque, L.; Bayot, Vincent; Huant, S.. A novel mesoscopic phenomenon: An analog of the Braess paradox in 2DEG networks. 16th International Conference on Modulated Semiconductor Structures (MSS-16) (Wroclaw, Poland). http://hdl.handle.net/2078.1/135509

13. Brun, B.; Rodrigues Martins, Frederico; Faniel, Sébastien; Hackens, Benoît; Bayot, Vincent; Huant, S.; Gennser, U.; Mailly, D.; Sanquer, M.; Sellier, H.. Scattering gate interferometry at a quantum point contact” 20th International Conference on Electronic Properties of Two-Dimensional Systems. 20th International Conference on Electronic Properties of Two-Dimensional Systems (EP2DS-20) (Wroclaw, Poland). http://hdl.handle.net/2078.1/135513

14. Faniel, Sébastien; Rodrigues Martins, Frederico; Bayot, Vincent; Hackens, Benoît; Desplanque, L.; Wallart, X.; Rosenow, B.; Melinte, Sorin. Dependence of the electronic transport on the microstructure in annealed Bi thin films. APS March Meeting (Baltimore, US). http://hdl.handle.net/2078.1/135515

15. Hackens, Benoît; Rodrigues Martins, Frederico; Faniel, Sébastien; Bayot, Vincent; Rosenow, B.; Desplanque, L.; Wallart, X.; Pala, M.; Sellier, H.; Huant, S.. Scanning gate spectroscopy of a quantum Hall island near a quantum point contact. APS March Meeting (Baltimore, US). http://hdl.handle.net/2078.1/135514

16. Hautier, Geoffroy; Miglio, Anna; Ceder, G.; Rignanese, Gian-Marco; Gonze, Xavier. Identification and design of novel p-type Transparent Conducting Oxides through high-throughput computing. European Materials Research Society Spring Meeting 2013 (Strasbourg, France). http://hdl.handle.net/2078.1/135713

17. Hautier, Geoffroy; Miglio, Anna; Ceder, G.; Rignanese, Gian-Marco; Gonze, Xavier. Finding low hole effective mass p-type Transparent Conducting Oxides through high-throughput computing. European Congress and Exhibition on Advanced Materials and Processes (Sevilla, Spain). http://hdl.handle.net/2078.1/135711

18. Bui, Thanh Nhan; Raskin, Jean-Pierre; Malet, L.; Godet, S.; Rodrigues Martins, Frederico; Faniel, Sébastien; Gonze, Xavier; Cabosart, Damien; Hackens, Benoît. Dependence of the electronic transport on the microstructure in annealed Bi thin films. APS March Meeting (Baltimore, US). http://hdl.handle.net/2078.1/135516

19. Gillet, Yannick; Giantomassi, Matteo; Gonze, Xavier. First-principles study of excitonic effects in Raman intensities. “18th ETSF Workshop on Electronic Excitations - Applications to functional and energy materials” (Luxembourg, Grand Duché du Luxembourg, du 01/10/2013 au 04/10/2013). http://hdl.handle.net/2078.1/136794

20. Gillet, Yannick; Giantomassi, Matteo; Gonze, Xavier. Excitonic effects in Raman intensities : an ab initio study. “ETSF Young Researchers’ Meeting 2013 - Beyond density-functional theory – Experimental and industrial connection” (Budapest, Hungary, du 20/05/2013 au 24/05/2013). http://hdl.handle.net/2078.1/136792

21. Gillet, Yannick; Abreu Araujo, Flavio. Status of the ABINIT GUI. "6th International ABINIT developer workshop 2013" (Dinard, France, du 15/04/2013 au 18/04/2013). http://hdl.handle.net/2078.1/136787

22. Gillet, Yannick; Giantomassi, Matteo; Gonze, Xavier. Bethe-Salpeter methodology and resonant Raman spectroscopy. "6th International ABINIT developer workshop 2013" (Dinard, France, du 15/04/2013 au 18/04/2013). http://hdl.handle.net/2078.1/136785

23. Hautier, Geoffroy. Finding new p-type Transparent Conducting Oxides through high-throughput computations. http://hdl.handle.net/2078.1/135057

24. Sudhakara Murthy, Prasad; Jacques, Laurent; Gonzalez Gonzalez, Adriana; Dubois, Xavier; Antoine, Philippe; Joannes, Luc. "Compressive Acquisition of Sparse Deflectometric Maps". SAMPTA 2013 (Bremen, Germany, du 01/07/2013 au 05/07/2013). http://hdl.handle.net/2078.1/134467

25. Abreu Araujo, Flavio; Gence, Loïk; Antohe, Vlad; Cros, Vincent; Piraux, Luc. Les nano-oscillateurs à transfert de spin à base de vortex fabriqués par électrodéposition dans des membranes en alumine nanoporeuse. XVe Colloque Louis Néel (Tours (France), du 19/03/2013 au 22/03/2013). http://hdl.handle.net/2078.1/129812

26. Paul, Jérôme; Verleysen, Michel; Dupont, Pierre. Identification of Statistically Significant Features from Random Forests. ECML workshop on Solving Complex Machine Learning Problems with Ensemble Methods (Prague, Czech Republic, du 27/09/2013 au 27/09/2013). http://hdl.handle.net/2078.1/133615

27. Hautier, Geoffroy; Miglio, Anna; Ceder, G.; Rignanese, Gian-Marco; Gonze, Xavier. A High-Throughput Computational Search for New Transparent Conducting Oxides. American Physical Society March Meeting 2013 (Baltimore, USA). http://hdl.handle.net/2078.1/135716

28. Seny, Bruno; Lambrechts, Jonathan; Legat, Vincent; Remacle, Jean-François. Development of a parallel third order explicit multirate scheme. YIC2013 Second ECCOMAS Young Investigators Conference (Bordeaux, du 02/09/2013 au 06/09/2013). http://hdl.handle.net/2078.1/135884

29. Dauvrin, Marie. COMETH. Diffuser les compétences culturelles des soignants par les relations interprofessionnelles.. 4ème colloque du Pôle de Recherche Interdisciplinaire en Sciences et Cliniques Infirmières (Woluwé-Saint-Lambert, 12/12/2013). http://hdl.handle.net/2078.1/135894

30. Hogenraad, R. L.
``War conjectures: Decoding words that make the risk of war legible''
Quantitative methods in art studies , Proceedings of international conference in memory of German A. Golitsyn 20–22 september 2012 pp 216-231 (2013).
Contact:robert.hogenraad@uclouvain.be

Dissertations


1. Leclercq, Guillaume. The velocity visuomotor transformation for manual tracking, prom. : Lefèvre, Philippe, 20/09/2013.

2. Cauwerts, Coralie. Influence of presentation modes on visual perceptions of daylit spaces, prom. : De Herde, André ; Bodart, Magali, 14/11/2013.

3. Beff, Laure. Analysis of soil water spatio-temporal variability at high resolution in a maize field, prom. : Javaux, Mathieu, 02/10/2013.