Le transfert d’informations entre les codes était le principal challenge de ce travail.
En effet les deux codes utilisés n’étaient pas conçus pour communiquer entre eux.
Le code à l’origine du code fluide FSI4CAV n’était pas écrit pour communiquer avec
l’extérieur tandis que le code CAST3M comptait des développements dans ce sens
mais sans que nous puissions directement les utiliser pour un couplage "two-way".
En effet, dans le paragraphe 3.4, nous avons vu que nous pouvions déjà proposer
une déformation du solide à partir de données de pression envoyées par le code
fluide. Cependant, nous souhaitions avoir une communication plus poussée avec
des échanges d’information à chaque pas de temps entre les deux codes. Pour cela
différentes possibilités s’offraient à nous :
• Utiliser des fichiers de données que chacun des codes lirait ou écrirait au besoin
(principe s’approchant du système utilisé pour les calculs "one-way").
• Un script python qui récupérerait les données d’un code pour les envoyer vers
l’autre code.
• L’utilisation d’une bibliothèque de calcul permettant d’envoyer et recevoir des
messages au sein d’une même architecture mémoire partagée.
La première solution a été rapidement exclue car elle demandait de faire de
nom-breux procédés de lecture et écriture de fichier qui sont très coûteux en temps. La
seconde option avait toutes les chances d’offrir des résultats intéressants, mais elle a
été abandonnée au profit de la troisième solution qui permettait d’être intégrée
di-rectement dans l’exécution de chacun des codes de calculs . De plus, la bibliothèque
utilisée : MPI, présentait l’avantage d’être aussi bien utilisable en langage C (code
de mécanique des fluides) qu’en langage Fortran (code de mécanique des solides).
4.3.1 Message Passing Interface
Message Passing Interface est une norme conçue en 1994 qui réunit une bibliothèque
de fonctions open source permettant de faire communiquer des ordinateurs à
dis-tance ou des multiprocesseurs. Cette bibliothèque est utilisable aussi bien avec le
langage C/C++ (FSI4CAV) que Fortran (CAST3M). Le principe de cette
biblio-thèque est donc de faire communiquer les processeurs entre eux par passage de
messages. Elle est couramment utilisée aujourd’hui pour paralléliser les codes de
calcul sur des architectures multi-processeurs composés chacun de plusieurs cœurs
de calcul. Ces processeurs ont chacun une mémoire propre qu’ils ne partagent pas
avec leurs voisins. Les cœurs de calcul ont accès à une mémoire commune, la
mé-moire du processeur (aussi appelé nœud de calcul) dans laquelle ils peuvent lire et
modifier des informations. Un exemple de parallélisation d’un code de calcul va être
de découper le domaine de calcul entre les différents processeurs. Chacun de ces
sous-domaines aura des informations en bord de domaine qui seront utiles pour les
autres sous-domaines. La bibliothèque MPI va être en charge de la communication
entre ces processeurs pour transmettre ces informations entre sous-domaines. La
fi-gure 4.9 illustre un exemple simple de ce type de communication.
Dans notre cas, nous avons deux codes qui au moment de leurs exécutions
res-pectives vont chacun générer deux processus. Chacun de ces deux processus va se
voir attribuer sa propre mémoire au sein des ressources de calcul demandées. Les
informations du code fluide ne seront pas accessibles directement par le code solide
et inversement. Aussi, nous allons utiliser la bibliothèque MPI afin de faire
commu-niquer ces deux codes entre eux.
Figure4.9 – Exemple de parallèlisation sur deux nœuds.
Une difficulté supplémentaire s’est présentée à ce stade du travail : les codes de
calculs que nous utilisions étant déjà parallélisés, il y avait un risque de conflit entre
les communications internes à chacun des codes. Pour le code fluide ce problème
n’en est en fait pas un car la parallélisation a été effectuée avec la bibliothèque
OpenMP qui diffère de la bibliothèque MPI. Les messages d’échanges internes au
code ne risqueront pas d’être confondus avec les messages de communication avec
l’extérieur car ils ne sont pas émis par les mêmes bibliothèques. Par contre le code
solide est parallélisé à l’aide de la bibliothèque MPI. Les risques de conflits sont
réels entre messages à destination interne nécessaire au fonctionnement du code
et messages à destination externe utilisés pour le transfert d’information entre les
codes. Nous avons donc redéfini un communicateur interne au code solide à partir
du communicateur global MPI_COMM_WORLD nommé MPI_COM_CAST3M.
Celui-ci se chargera des échanges d’informations exclusivement nécessaires au
fonc-tionnement de CAST3M. Le communicateur MPI_COMM_WORLD sera lui chargé
des échanges d’informations entre CAST3M et FSI4CAV.
Le fonctionnement de ces échanges d’informations est résumé par la figure 4.10.
Chacun des codes a sa mémoire propre qui correspond aux cœurs qui lui sont
at-tribués. Sous chaque code, le type de communication est précisé en italique. Enfin
Figure4.10 – Fonctionnement des deux codes couplés sur un même nœud de calcul.
l’échange entre les deux codes est effectué par un troisième type de communicateurs,
lui aussi en italique.
À présent, nous allons aborder le détail de la communication entre les deux codes
en s’intéressant à l’utilisation pratique de la bibliothèque MPI.
4.3.2 Communication entre les codes
Comme précisé dans le paragraphe précédent, chacun des deux codes va utiliser la
bibliothèque MPI pour communiquer avec son alter-ego. Le code FSI4CAV utilise
la bibliothèque pour langage C, tandis que le code CAST3M qui est écrit en Esope,
un dérivé du fortran (3.3.1) fera appel à la bibliothèque Fortran. D’un point de vue
pratique, il a fallu implémenter des fonctions dédiées à la communication dans
cha-cun des codes. Dans FSI4CAV, ce travail s’est limité à ajouter des fonctions faisant
appel aux directives MPI voulues. Par contre, dans CAST3M, nous avons eu besoin
de comprendre clairement le déroulement du code afin d’introduire et d’effectuer les
appels aux fonctions de communication dans les séquences d’instruction adaptées.
Pour cela, nous nous sommes appuyés sur les récents développements de CAST3M
dans lequel un nouveau type d’opérateur appelé "collaborateur", dédié à la
com-munication, a été intégré. Ces nouveaux opérateurs avaient pour but d’obtenir un
niveau supérieur de parallélisme dans CAST3M et à plus long terme de permettre
à CAST3M d’échanger avec d’autre codes.
Pour faire fonctionner cette communication inter-codes, nous avons fait appel
aux fonctions suivantes :
• MPI_Comm_split : Création des communicateurs.
• MPI_Comm_size : Calcul du nombre total de processus en communication.
• MPI_Comm_rank : Numéro d’identification du processus.
• MPI_Finalize : Fin de l’environnement de communication.
L’ensemble de ces fonctions vont mettre en place et paramétrer
l’environne-ment de communication. Elles sont toutes appelées au début du calcul
(excep-tée MPI_Finalize qui termine le calcul) respectivement dans chacun des codes.
Lorsque chacune de ces fonctions a effectué sa tâche, chaque code va dérouler
son fonctionnement respectif et les échanges d’informations pourront démarrer.
• MPI_Comm_Send : Envoi de données par un processus.
• MPI_Comm_Receive : Réception de données par un processus.
Les communications effectuées entre les deux codes sont dites bloquantes. Le code
attendra que l’instruction soit correctement effectuée avant d’exécuter la séquence
d’instructions suivantes. Ceci signifie que chaque code envoyant une instruction
at-tendra que celle-ci ait bien été envoyée avant de poursuivre son exécution. De même,
un code attendant une information n’ira pas au-delà tant que cette information ne
sera pas reçue. Il faut cependant noter que le code ayant envoyé l’information ne
s’as-surera pas de la bonne réception du message avant de poursuivre son déroulement.
Il existe des fonctions permettant d’optimiser ces envois-réceptions de messages, qui
notamment ne bloquent pas la communication mais elles n’ont pas été utilisées dans
ce travail.
Pour communiquer dans le code CAST3M, nous avons utilisé les opérateurs
col-laborateurs (directive d’appel : COLL). Ce type d’opérateur est associé à un mot
clef. L’utilisation des mots-clefs "début", "nombre", "rang" et "fin" va permettre
d’effectuer toute la mise en place de l’environnement MPI. Il existe aussi des
col-laborateurs, liés aux envois et réceptions d’informations, appelés par les mots-clés
envoyer et recevoir. Cependant, ils avaient vocation à effectuer de la communication
au sein d’un même processus de CAST3M. Nous avons donc générer nos propres
outils collaborateurs dédiés à une communication externe à CAST3M. Ces deux
collaborateurs sont appelés avec les mots-clefs "toext" et "fromext" dans le fichier
GIBIANE. Ce sont les seuls à utiliser le communicateur COMM_WORLD. Ils ont
été écrits de façon à communiquer avec FSI4CAV. Ils permettent d’envoyer des réels
ou des tableaux de réels. La figure 4.11 résume l’ensemble des interactions entre les
deux codes grâce à l’environnement MPI.
Figure4.11 – Principe résumé d’une itération de couplage
Nous retrouvons les trois étapes du déroulement du calcul liées à la communication :
mise en place de l’environnement, boucle temporelle et fermeture de l’environnement.
À l’issue de cette partie, nous avons abordé l’ensemble des points importants
per-mettant d’avoir un couplage fonctionnel entre les deux codes : principe, itération de
couplage et communication entre les codes. Nous pouvons donc aborder les différents
résultats de calculs couplés et leur comparaison avec des calculs non-couplés.
Dans le document
Interaction Fluide-Structure et Érosion de Cavitation
(Page 165-170)