Calcul parallèle du graphe de connectivité

dépendances. Une fois que toutes les dalles ont été traitées localement, ce graphe dépendance est résolu en utilisant à nouveau l’algorithme de compression de chemins toujours à l’image de ce qui est fait dans la version incore pour ce qui concerne l’éti-quetage global des cuvettes. En pratique nous ne créons pas de labels spécifiques en interne pour ce traitement,GdgF Di stocke des liens entre des pixels. Une structure de données M api<PosPuits,IdPuits> permet d’associer à chaque pixel racine son identifiant. Cette structure de données permet de connaître l’identifiant d’un pixel racine même si la dalle qui le contient n’est pas chargée en mémoire ce qui permet d’éviter de nombreux chargement/déchargements. De même les pixels qui sont aux bords de Di,sont maintenus en mémoire dans une structure de donnéesM apB_Di = {p, idPuits}. Ceci évite de recharger toutes les dalles une à une pour accéder à ces pixels pour la suite du processus qui se déroule à présent exactement comme dans la version incore de ParaFlow, illustrée dansSection 6.1.2.4.

Finalement, l’étiquette des pixels correspondant aux puits secondaires est rem-placée par celle de leur racine. Cette phase est totalement parallèle et réalisée par un parcours linéaire pour tous les pixels apres chagement séquentiel de chaque dalleGerej∈listedalles.

9.3 Calcul parallèle du graphe de connectivité

L’objectif de la construction du graphe de connectivité a été présenté dans la Section6.1.3. Ce graphe de connectivitéGC₀va reconstituer la connectivité entre les cuvettes pour l’ensemble du MNT. Chaque cuvette (étant un bassin versant au premier niveau) représente un sommet et est identifiée par un numéro unique.

Dans la version incore de Paraflow, les connectivités locales au processeurProc.

i entre des cuvettes sont simplement déduites lors d’un parcours linéaire de tous les pixels deDi. Lorsque deux pixels adjacent n’appartiennent pas à la même cuvette, une nouvelle arête entre ces deux cuvettes est ajoutée dans GC_i⁰ si elle n’était pas encore présente. Le poids de l’arête correspond à la hauteur maximale entre ces deux pixels. Si elle était déjà présente, l’arête est mise à jour si le nouveau poids est inférieur à celui déjà trouvé.

Comme dans la phase précédente, nous proposons de charger en mémoire dalle par dalle les données deDi. Nous ne manipulons à un instant donné que les données dedalleGerej. Mais cela se révèle insuffisant siGC_i⁰est très important comme cela est souvent le cas pour les très gros MNT au début du calcul. Nous complétons donc notre méthode en sauvegardant des portions de GC_i⁰ au cours du calcul. La difficulté réside dans le fait qu’il n’est pas possible de savoir si une donnée de GC_i⁰ ne risque pas d’être mise à jour alors qu’elle est déchargée sur le disque. Dans ce cas nous choisissons de stocker cette nouvelle information et de résoudre le conflit ultérieurement dans une seconde phase de traitement.

Voici la démarche plus précisément. L’idée consiste à localement détecter, pour chaquedalleGerej, toutes les arêtes de poids minimal entre les cuvettes. Nous

choi-sissons de distinguer trois types d’arêtes :

1. Le premier type contient toutes les arêtes de poids minimal qui aboutissent aux sommetsstels que le puitsscorresponde à un pixel appartenant àdalleGerej. Ces arêtes sont insérées dans un ensemble notégcGere⁰_i[j].

2. Le deuxième est l’ensemble de toutes les arêtes de poids minimal qui abou-tissent aux sommetsstels que le puitsscorresponde à un pixel n’appartenant pas àdalleGerej. Si ce pixel appartient àdalleGerek (k6=j) alors cet arête est insérée dansgcGere⁰_i[k].

3. Le dernier est l’ensemble de toutes les arêtes de poids minimal qui aboutissent aux sommetsstels que le puitsscorresponde à un pixel n’appartenant pas à Di. Une telle arête est insérée dansgcExt⁰_i[r].

L’ensemblegcGere⁰_i[j]qui correspond au premier type d’arêtes est généralement très majoritaire. En effet les sous domaines des dalles contiennent une multitudes de cuvettes souvent entièrement contenues dans une seule dalle. Cela signifie que gcGere⁰_i[j]contient majoritairement des arrêtes dont il ne sera pas nécessaire de mo-difier la valeur de hauteur à l’examen des valeurs du reste du domaineDi. Il est donc judicieux de privilégier cet ensemble pour un stockage sur disque et ainsi libérer de la mémoire. L’ensemblegcGere⁰_i[j]est sauvegardé sur disque à chaque changement de dalle. Les deux autres ensembles, bien moins volumineux sont conservés en mémoire.

Ils sont mis à jours dès que de nouvelles données apparaissent lors du chargement desdalleGerej^′. Notons que certaines de ces données sont mises sur disque lors du traitment des dallesdalleGerej^′qui stockent sur disque lesgcGere⁰_i[j^′]. Notons aussi que lors du traitement de dalleGerej^′, nous gardons en mémoire dans gcGere⁰_i[j]

d’éventuelles arêtes de type 2 qui aboutissent à des puits qui correspondent à des pixels appartenant àdalleGerej.

Ensuite exactement comme dans la version incore, nous pratiquons une phase d’échange des arrêtes de gcExt⁰_i entre tous les processeurs. Chaque processeur va donc obtenir un ensemble de nouvelles arêtes, notégcRecvi, calculées par les autres processeurs.

Après avoir chargé toutes les dalles une première fois, et avoir réalisé la phase d’échanges, le traitement consiste à recharger une par une toutes les sauvegardes sur disque de gcGere⁰_i[j] et à les mettre à jour avec les données contenues dans gcGere⁰_i[j] et dans gcRecvi. Une seule version des arrêtes est conservée avec une hauteur minimale. Nous obtenons le graphe de connectivité local sur les disques de la machine parallèle.

Notons que la technique “out-of-core” prend aussi en compte la règle Ω (voir Section5.2.4).

9.4. Calcul parallèle hiérarchique des bassins versants 119

9.4 Calcul parallèle hiérarchique des bassins versants

DansSection6.2, nous avons présenté une implémentation parallèle de l’algo-rithme Borůvka afin de calculer un arbre couvrant de poids minimum et nous avons aussi montré comment mettre en œuvre cette méthode dans le calcul de la hiérarchie des bassins versants. Ce calcul commence à partir d’un graphe de connectivitéGC⁰ au premier niveau. L’idée consiste à progressivement fusionner les sommets niveau par niveau.

La parallèlisation de notre méthode, est réalisée en subdivisant en blocs de som-mets le grapheGC⁰. Chaque blocGC_i⁰est distribué à un processeurProc. i. Cette distribution vise à minimiser le nombre d’arêtes externes reliant deux sommets ap-partenant à deux domaines différents. Dans le cas de données massives, le graphe GC_i⁰, peut ne pas tenir en mémoire, et donc on peut le redécouper en sous-graphe GC_i⁰[j]de telle sorte qu’un processeurProc. ipuisse charger chacun des sous-graphes GC_i⁰[j] en mémoire centrale. Chacun des sous-graphes est chargé et, progressive-ment , on construit une nouvelle structure de donnée, notéeGCW ithM Ci, qui est bien plus légère que GC_i⁰ et qui est un graphe de connectivité dans lequel on ne conserve pour chaque sommet que les arrêtes dont le poids est minimal. Ce graphe GCW ithM Cidoit pouvoir tenir dans la mémoire d’un processeur. Le reste du pro-cessus est réalisé surGCW ithM Ciil est identique à la version incore. Notons toute-fois que le calcul du graphe de connectivité au rang supérieur nécessite d’utiliser les sous graphes GC_i⁰[j]pour déterminer les nouvelles arêtes entre les nouveaux som-mets. Ceci peut être réalisé en chargeant séparément dans le temps les différents GC_i⁰[j].

9.5 Tests

Les premiers tests de Paraflow-OOC ont été réalisés sur la machine Dell (2Go de RAM, et processeur bi-core 2,2GHz, Ubuntu 10.0.4, OpenMPI version 1.4.1).

Le temps de calcul de la partie calcul des cuvettes pour un seul processus sur le MNT de nigeretendu (30.001×42.001) est environ de 311 minutes. Ce temps inclu le chargement et la sauvegarde des données. ParaFlow-OOC donne strictement les mêmes résultats pixel par pixel, pour le calcul des cuvettes, que ParaFlow.

La version ParaFlow-OOC actuelle est encore un prototype qui demande à être amélioré notamment sur les premières étape de l’algorithme de Borůvka. Cependant les premiers résultats sont concluants et valident la méthodologie employée. Cela nous permet d’envisager une version performante de ParaFlow-OOC qui aura des performances comparable à celles de TerraFlow sur une machine de bureau et qui aura en plus la capacité d’utiliser les ressources d’une machine parallèle lorsqu’elle est disponible.