Parallélisme et MPI

[Mars105]

j'ai aussi été très pris ces temps si...

au final si je doit faire du paralèlisme autaut coder une armature moi même, je perdrais moin de temps je pense

quand j'aurais finis les autres projets sur les quels je suis en ce moment je pense que je vais me lancer dans un truque simple de partage de calcule multi plateformes. je vous redis si ça se fait.

[fafaro]

Bon, allez, quelques lignes sur les idées de communications bloquantes et non bloquantes. Ce sera purement "théorique" aujourd'hui.

Lorsque le processus 0 envoie un message au processus 1, il a en gros deux façons de le faire. La première : il envoie le message et ne retourne à son fil d'exécution que lorsqu'il est certain que le message est correctement parti, c'est l'envoi bloquant. La deuxième : il envoie le message et retourne de suite à son fil d'exécution sans savoir si l'envoi s'est bien passé, c'est l'envoi non bloquant. En règle général, il est préférable d'utiliser les envois non bloquant, qui ne sont pas trop risqués et qui permettent de gagner du temps.

Il existe la même chose pour les réceptions, et là c'est plus critique. Vous pouvez de la même façon recevoir un message et ne poursuivre que lorsque vous êtes certains que le message est bien arrivé, et son contenu est stocké au bon endroit, dans la bonne variable : c'est la réception bloquante. Et vous pouvez poster la réception, et continuer aussitôt, mais là, vous ne savez pas si le message est bien arrivé, si vous avez bien rempli votre variable titi avec le contenu du message : c'est la réception non bloquante.

Pour ce qui concerne la réception, il faut faire très attention en utilisant la réception non bloquante. En particulier, pour l'utiliser, il faut être sûr de ne pas avoir besoin du contenu du message juste après sa réception. Dans ce cas là, vous pouvez réceptionner de façon non bloquante un tableau d'entiers par exemple, continuer l'exécution puisque vous savez que vous n'avez pas besoin de ce tableau dans l'immédiat, puis, lorsque vous devez manipuler ce tableau, vous vous arrêtez pour vous assurer que le message est bien arrivé.

Voilà pour l'idée. Si vous avez des question, allez-y.

[theocrite]

Ajouté aux meilleurs liens de la section. J'aurais du le faire avant, mais j'avais la flemme de lire et pas trop de temps.

C'est un sujet très intéressant

Ce serait bien si le topic devait continuer à grandir que tu centralises les réponses aux questions dans tes premiers posts et que tu y mette les tutos ou les liens vers tes posts explicatifs. Enfin si tu as le temps bien sûr. Je pourrais éventuellement t'aider si j'ai le temps et le niveau pour.

Pour en discuter ou des critiques (par exemple sur la description du topic dans les meilleurs liens) et éviter de trop pourrir ce topic, je vous invite à le faire au bar

[fafaro]

Salut tout le monde !

J'ai un peu honte d'avoir laissé le topic couler en deuxième page , alors je me reprends. Et comme le travail se calme un peu, j'ai le temps de faire un vrai post.

theocrite, merci pour l'ajout aux liens Je vais essayer de modifier un peu le premier post pour guider vers les posts suivants.

Aujourd'hui, communications collectives avec MPI. Je ne parlerai que des 4 principales fonctions : MPI_Bcast, MPI_Scatter, MPI_Gather et MPI_Reduce.

Petit préambule avant d'attaquer, ces fonctions de communications collectives permettent de manipuler un message sur tous les processus d'un communicateur (rappel : un communicateur est une liste, un ensemble, de processus). Comme je n'ai pas encore parlé des fonctions permettant de créer des communicateurs, tous les exemples utiliserons le communicateur par défaut, MPI_COMM_WORLD, qui contient tous les processus de l'application parallèle en cours d'exécution. Dernière chose : l'appel à ces fonctions doit être identique sur tous les processus.

Bon, commençons par MPI_Bcast. Cette fonction permet à un processus d'envoyer un message à tous les autres processus du communicateur. Ainsi, imaginons que le processus 0 doive envoyer un tableau de 10 entiers tab vers tous les autres processus. Ceci s'effectue en ajoutant simplement la ligne

MPI_Bcast(tab, 10, MPI_INT, 0, MPI_COMM_WORLD) ;

dans le(s) code(s) exécutés sur chaque processeur.

Le 4ème argument est très important. Il désigne la racine de la communication. La racine est l'expéditeur du message, tous les autres sont récepteurs. Le 1er argument est l'adresse contenant le message pour la racine, et l'adresse où sera stocké le message pour les autres. Le 2ème argument est la taille du message (en nombre d'éléments) et le 3ème le type de chaque élément. Le 4ème est donc la racine, et le 5ème le communicateur.

Passons à MPI_Scatter. Cette fonction permet à un processus de partager un tableau entre tous les autres processus du communicateur. Si le communicateur cotient 10 processus, et que le processus 0 veut garder le 1er élément de tab, envoyer le 2ème élément au processus 1, le 3ème élément au processus 2, etc..., alors il suffit pour cela d'ajouter la ligne

MPI_Scatter(tab, 1, MPI_INT, element, 1, MPI_INT, 0, MPI_COMM_WORLD) ;

dans le(s) code(s) exécutés sur chaque processeur.

L'avant-dernier argument est une nouvelle fois la racine, et a le même rôle que pour MPI_Bcast. Les 3 premiers arguments n'ont d'importance que pour la racine. Ils désignent l'adresse du message, le nombre d'éléments envoyés à chaque processus (dans notre cas, 1, puisqu'on partage un tableau de taille 10 en 10 parts) et le type de ces éléments. Le nombre d'éléments ne doit en aucun cas être le nombre total d'éléments envoyés (dans notre cas 10). Les 3 arguments suivants sont l'adresse où sera stocké le message, le nombre d'éléments reçus et le type de ces éléments. Le dernier argument est encore une fois le communicateur.

Voyons maintenant MPI_Gather, qui effectue l'opération inverse de MPI_Scatter. MPI_Gather permet de collecter des messages provenant de tous les processus et d'en stocker le contenu dans un tableau. Si vous voulez assembler sur le processus 0 les différentes valeurs de la variable mon_elt que connaissent les 10 processus et les stocker dans un tableau tab dans leur ordre, vous pouvez le réaliser en écrivant la ligne

MPI_Gather(mon_elt, 1, MPI_INT, tab, 1, MPI_INT, 0, MPI_COMM_WORLD) ;

dans le(s) code(s) exécutés sur chaque processeur.

La racine est de nouveau l'avant-dernier argument, mais elle désigne cette fois le processus collecteur. Les 3 premiers arguments concernent les messages envoyés (adresse, taille, type), et les trois suivants les messages reçus (ils ne concernent donc que la racine). Les arguments des messages reçus sont l'adresse du tableau où seront rangés les contenus des messages arrivant, la taille de chaque message arrivant et le type de données du message.

Enfin la fonction MPI_Reduce. Cette fonction permet de collecter des messages provenant de tous les processus et d'effectuer une opération sur leur contenu avant de stocker le résultat de cette opération. Imaginons que vous ayez un maximum local sur chaque processus et que vous désiriez récupérer un max global sur le processus 0. Rien de plus simple ! Ecrivez simplement cette ligne

MPI_Gather(max_local, max_global,1, MPI_INT, MPI_MAX, 0, MPI_COMM_WORLD) ;

dans le(s) code(s) exécutés sur chaque processeur.

L'avant-dernier argument est toujours la racine, ici le processus recevant les messages et exécutant l'opération sur leur contenu. Le 1er argument est le message envoyer, le 2ème la variable où sera rangé le résultat de l'opération effectuée sur les messages, le 3ème la taille du message, le 4ème le type de donnée, le 5ème l'opération (et le dernier le communicateur). L'opération peut être un max, un min, une somme, un produit, ou une opération logique diverse (ou, et, ou exclusif,...).

Voilà, je m'arrête ici aujourd'hui. J'attends vos questions.

Ciao !

[onlyann]

Bonjour, je réalise un programme en MPI en langage C et j'ai besoin dans une boucle d'envoyer des elements a un autre processeur. Le nombre d'elements que je cherche a envoyer change a chaque itération. Il me faut donc indiquer au processeur qui va recevoir les données combien il est sensé en recevoir.

Une première solution serait d'effectuer 2 envois, un premier indiquant combien d'elements on va envoyer au processeur et un 2e qui contient les données a envoyer. Très bien. Mais cette méthode n'est pas vraiment optimisée puisque on effectue plusieurs envois/receptions et j'aimerais bien le faire en une seule fois.

Une autre solution serait de créer une sctructure qui contient le nb d elements dans un membre et les elements a envoyer dans un second membre, puis d'envoyer ce type. Mais c'est assez bourrin comme méthode.

Donc, n y aurait-il pas une fonction MPI que je n'ai pas vue faite pour ce genre de cas ?

Merci

[fafaro]

Désolé d'avoir mis si longtemps pour répondre

Je ne vois pas comment éviter le premier message, contenant la taille du suivant. En tout cas, je procède de cette façon aussi, donc si tu trouves une meilleure solution ça m'intéresse énormément

[ghostrider701]

fafaro, t'y connais tu en mpi2 notamment en gestion dynamique de process ?

Le mpi1 ne fait pas mon bonheur :(

[fafaro]

Houla, j'ai encore bien laissé couler le sujet

Je m'y connais un peu, mais poins bien qu'en MPI1 parce que je n'ai pas beaucoup utilisé MPI2. Principalement parce que le standard MPI2 n'est pas encore totalement intégré aux distributions libres de MPI d'ailleurs.

J'ai un peu utiliser la getion des processus, mais seulement pour des opérations élémentaires, comme lancer un processus en cours d'exécution par exemple.

Pose toujours tes questions si tu en as, et j'essaierai d'y répondre de mon mieux

Sinon, je vais essayer de trouver le temps de faire un résumé des principales fonctions de communication point à point la semaine prochaine pour compléter le sujet.

[fafaro]

Allez hop, un petit message sur les détails des communications point à point. Je le promets depuis longtemps, je m'excuse du retard.

On va commencer par les commandes de base, à savoir MPI_Send et MPI_Recv. Ces deux commandes sont les plus simples à utiliser. L'utilisateur qui ne veut pas se poser trop de questions sur ce qui se passe en détail peut se fier à MPI pour gérer les détails et utiliser ces 2 commandes. Le détail :

MPI_Send(tab, nb_elt, MPI_INT, dest, num, MPI_COMM_WORLD)

MPI_Recv(tab, nb_elt, MPI_INT, prov, num, MPI_COMM_WORLD)

La signification de tout ça : tab est le pointeur vers la variable que vous voulez envoyer ou vers la variable dans laquelle vous voulez stocker ce que vous réceptionnez ; nb_elt est le nombre d'éléments (entier) que vous envoyez ou récetionnez ; MPI_INT est le type des éléments que vous envoyez/réceptionnez (ici des entiers donc) ; dest est le numéro du processus vers lequel vous envoyez votre message et prov le numéro du processus qui vous envoie le message que vous réceptionnez ; num est un numéro, un entier, qui caractérise le message et permet de différencier plusieurs messages qui transitent entre les mêmes processus ; MPI_COMM_WORLD est le communicateur dans lequel vous travaillez (ici le communicateur par défaut).

Dans une distribution standard de MPI, MPI_Send est non bloquant et MPI_Recv est bloquant.

Il est possible de forcer des communications à être bloquantes ou non.

Communications bloquantes

La réception bloquante s'effectue avec MPI_Recv.

L'envoi bloquant peut être de deux types : MPI_Ssend ou MPI_Rsend. Ce premier type d'envoi est considéré comme terminé lorsque le message est reçu, le second se termine instantanément mais la commande de réception correspondante doit être exécutée avant l'envoi (utilisation très particulière). Les arguments de ces deux commandes sont les mêmes que ceux du send classique.

Je gardes les communications non bloquantes pour plus tard, j'ai du travail qui vient de me tomber dessus.

[Celos]

C'est vraiment dommage que je n'ai pas pensé à chercher sur le forum de pci, je pense que t'aurais pu m'aider.

Cette année j'ai fais un projet (avec un binome) qui consistait à faire un décryptage distribué de RSA. Enfin c'etait pas un algorythme tres poussé, et on a fait ce qu'on a pu (en java) et on l'a fini. Voila c'etait my life :)

edit: je viens de me rendre compte que ce topic a plus d'1 an lol

[tsubasaleguedin]

Mortel le topic !

Merci !

[fafaro]

Holala, y a eu des visites depuis la dernière fois. Faut que je refasse un tour ici, pour compléter un peu le topic.

[maxialec]

coucou tout le monde, je compte me mettre aussi sur mpi mais je voulais d'abord remercier fafaro.

En lisant tous les messages que vous avez écrit , j'ai trouvé des réponses à la plupart de mes questions.

alors merci merci beaucoup

Mais il reste une question qui me travaille vraiment beaucoup:

est ce que l'application parallèle est sur la machine principale uniquement, ce qui voudrai dire que mpi ne s'occupe pas que de l'envoi et de la reception des messages mais aussi de la repartition des taches en quelques sortes ou au contraire on dois mettre les petits codes comme vous dites dans chaque machine et donc chaque processus qu'on a donc mis sur chaque machine attend les données qu'il doit traiter ensuite renvoyer le résultat à la machine emetrice.

Je peux comprendre que ça soit une question un peu bête et superflue , mais ça me travaille vraiment

une deuxieme question :(qui peut etre toute aussi "stupide" que la premiere):

pour créer un cluster et donc lancer des applications parallèles , est ce qu'il suffirait d'avoir un petit reseau(mais c'est evident ) et installer mpi sur chaque machine (sachant que je travaille sous linux (ubuntu))?????????

Voilà

Merci

[fafaro]

coucou tout le monde, je compte me mettre aussi sur mpi mais je voulais d'abord remercier fafaro.

En lisant tous les messages que vous avez écrit , j'ai trouvé des réponses à la plupart de mes questions.

alors merci merci beaucoup

Mais il reste une question qui me travaille vraiment beaucoup:

est ce que l'application parallèle est sur la machine principale uniquement, ce qui voudrai dire que mpi ne s'occupe pas que de l'envoi et de la reception des messages mais aussi de la repartition des taches en quelques sortes ou au contraire on dois mettre les petits codes comme vous dites dans chaque machine et donc chaque processus qu'on a donc mis sur chaque machine attend les données qu'il doit traiter ensuite renvoyer le résultat à la machine emetrice.

Je peux comprendre que ça soit une question un peu bête et superflue , mais ça me travaille vraiment

une deuxieme question :(qui peut etre toute aussi "stupide" que la premiere):

pour créer un cluster et donc lancer des applications parallèles , est ce qu'il suffirait d'avoir un petit reseau(mais c'est evident ) et installer mpi sur chaque machine (sachant que je travaille sous linux (ubuntu))?????????

Voilà

Merci

Toutes mes excuses pour la réponse très tardive

Pour la 1ère question, il faut que l'exécutable se trouve sur chacun des noeuds. Souvent, le /home est monté sur chaque noeud de calcul, donc les exécutables sont disponbibles sur chaque machine.

J'avais souvenir du contraire lorsque je commençais à utiliser MPI il y a 5-6 ans, mais j'ai peut-être rêvé. Ou alors ça dépend des distributions.

Et pour ta deuxième question, c'est exactement ça. Si tu as quelques machines en réseau sur lesquelles tu installes MPI, tu pourras les utiliser comme un petit cluster. Je te conseille de faire un montage nfs pour avoir un répertoire commun sur chaque machine, comme ça tu mets les exécutables dans ce répertoire et tout roule.

[16ar]

Hop je poste un ptit message dessus pour retrouver ca facilement :)

Je vais potasser quand j'aurais le temps.

En attendant, vu que les gens qui squattent ce post s'interessent au sujet, j'aurais quelques questions (je n'ai pas encore lu le post en entier, c peut etre indiqué dedans...)

Est ce qu'il est possible d'avoir une application lancée sur une sorte de machine virtuelle créée par une aggregation de noeud dans un cluster ?

En gros, on configure un cluster de 3 machines... Les 3 sont identiques, pas de master/slave. On lance un daemon sur chacune des machines et hop, du coup les 3 se reconnaissent et crééent une machine virtuelle accessible via ssh ou autre. Cette machine virtuelle pourrait ensuite lancer un processus multithread qui lui irait sur n'importe quel noeud, suivant le scheduler de la machine virtuelle.

Est ce que ca existe ? Ou y'a toujours des histoires de master/slave ? (parce que bon, si le master tombe en rade, le cluster il sert un peu a rien du coup ...)

D'avance merci !

[fafaro]

Hop je poste un ptit message dessus pour retrouver ca facilement :)

Je vais potasser quand j'aurais le temps.

En attendant, vu que les gens qui squattent ce post s'interessent au sujet, j'aurais quelques questions (je n'ai pas encore lu le post en entier, c peut etre indiqué dedans...)

Est ce qu'il est possible d'avoir une application lancée sur une sorte de machine virtuelle créée par une aggregation de noeud dans un cluster ?

En gros, on configure un cluster de 3 machines... Les 3 sont identiques, pas de master/slave. On lance un daemon sur chacune des machines et hop, du coup les 3 se reconnaissent et crééent une machine virtuelle accessible via ssh ou autre. Cette machine virtuelle pourrait ensuite lancer un processus multithread qui lui irait sur n'importe quel noeud, suivant le scheduler de la machine virtuelle.

Est ce que ca existe ? Ou y'a toujours des histoires de master/slave ? (parce que bon, si le master tombe en rade, le cluster il sert un peu a rien du coup ...)

D'avance merci !

Non, en fait l'histoire de master / slave - je préfère parler de machine frontale / noeuds de calcul pour les machines, je parle de master / slave pour les applications plutôt - c'est plus lié à l'administration du cluster et à l'accès au cluster depuis l'extérieur. La machine frontale est le point d'accès au cluster, celle à partir de laquelle tu lances tes applications parallèles.

Mais quand tu lances le daemon mpi sur un ensemble de machine - tout le cluster ou juste une partie de celui-ci, tu peux choisir - c'est un peu comme si tu faisais une machine virtuelle. Ton daemon va écouter les appels MPI, ce ne sera pas à proprement parlé du multithread par contre, parce qu'avec MPI tu as des applications bien distinctes sur chacun des noeuds de calcul. Et pour ce qui est du scheduler, il n'y en a pas vraiment, la commande mpirun envoie les différentes applications MPI suivant l'ordre dans lequel les daemons ont été lancés (à ma connaissance en tout cas).

[16ar]

Zut, donc un cluster sera en rade une fois le frontal en rade. Juste ?

Bon et faut que je lise le topic avant de poser d'autres questions stupides

[fafaro]

Zut, donc un cluster sera en rade une fois le frontal en rade. Juste ?

Bon et faut que je lise le topic avant de poser d'autres questions stupides

Oui, en général le cluster est down si la frontale est down. Sur les grosses installations, il y a des redondances permettant une bonne tolérance aux pannes, mais sur les petites machines, ce n'est pas le cas.

[titus-brutus]

salut fafaro

J'ai 1 soucis je voudrais faire du mpi chez moi mais le probleme c'est que la commande MPiCC pour la compilation fonctionne impeccable mais la la commade d'execution mpirun ne marche pas , elle tourne en faite l'exection n'a pas de fin et lorsque je fais

ctrl -c j'ai se message qui saffiche:

It seems that [at least] one of the processes that was started with

mpirun did not invoke MPI_INIT before quitting (it is possible that

more than one process did not invoke MPI_INIT -- mpirun was only

notified of the first one, which was on node n0).

mpirun can *only* be used with MPI programs (i.e., programs that

invoke MPI_INIT and MPI_FINALIZE). You can use the "lamexec" program

to run non-MPI programs over the lambooted nodes.

je comprend vaguement ce que ca veut dire je rentre alors dsl'ernvironement lam en tapant lamboot

et refais un mpirun ca ne marche pas non plus pourquoi a tu une idée

[fafaro]

It seems that [at least] one of the processes that was started with

mpirun did not invoke MPI_INIT before quitting (it is possible that

more than one process did not invoke MPI_INIT -- mpirun was only

notified of the first one, which was on node n0).

mpirun can *only* be used with MPI programs (i.e., programs that

invoke MPI_INIT and MPI_FINALIZE). You can use the "lamexec" program

to run non-MPI programs over the lambooted nodes.

Salut,

Apparemment ton programme est buggé. Ce message signifie en gros que l'un des processus s'est arrêté avant d'exécuter la commande MPI_Init.

Est-ce que tu pourrais copier coller la source de ton code ici pour qu'on regarde ce qui ne va pas ?

Edit : si je mets un peu de temps à répondre, n'hésitez pas à m'envoyer un MP

[fernyqc]

Bonjour à tous,

Premièrement, ce thread de discussion est très intéressant et le sujet aurait avantage à devenir un forum et non simplement un thread. Je suis nouveau sur MPI-2 et j'avoue chercher de bonnes références pour me débrouiller.

Je me présente...je suis un étudiant en maîtrise à l'université de Sherbrooke au Québec. Dans mon projet de recherche, je contrôle plusieurs robots mobiles et j'utilise MPI pour distribuer mes composants logiciels sur chacun des robots. Certains de ces composants sont développés par d'autres étudiants et ils n'utilisent pas MPI. Je ne peux donc pas communiquer avec ces process via la spécification.

Les programmes en question acceptent des arguments à la ligne de commande tel un nom de fichier contenant leur configuration XML. La ligne de commande ressemble à ceci

monapplication -config ./MyConfiguration.xml

À l'interne, monapplication tente d'ouvrir le fichier ./MyConfiguration.xml, mais l'ouverture du handler de fichier échoue tout le temps. La raison est que le fichier n'est pas trouvé. Cependant, je vous assure que le fichier se trouve bel et bien là où je l'indique!!!

J'ai essayé de lancer mpiexec -n 1 monapplication -config ./MyConfiguration et ça fonctionne sans aucun problème. Là ou ça ne fonctionne pas c'est lors de l'utilisation de MPI_Comm_Spawn dans mon application MPI responsable de distribuer tous les process sur les robots. J'utilise MPICH2 comme implémentation.

Voici un aperçu du code :

	  MPI::Info info;
  const char *keys[2] = { "host", "wdir" };
  const char *values[2] = { hostname.c_str(), workingDirectory.c_str() };

  info = MPI::Info::Create();
  for (unsigned int i=0; i<2; i++) 
  {
	 info.Set(keys[i], values[i]);
  }

  intercomm = MPI::COMM_WORLD.Spawn(process.m_executableName.c_str(), argv, 1, info, 0);

  info.Free();

Dans info, wdir définit le répertoire de travail du process fils. Ainsi, le chemin relatif devrait fonctionner. Dans argv, il y a le nom du fichier de configuration à ouvrir. Ce que j'observe c'est que le processus fils est correctement appellé (j'ai affiché les arguments du main pour vérifier), mais l'ouverture du fichier de configuration échoue.

Est-ce que quelqu'un peut m'éclairer? Merci à l'avance

[tabouille]

Salut !

Donc j'ai un tit probleme avec MPI je doit fair une methode de tri en parrallellisation donc j'envoie le tableau avec MPI_Send lautre processeur fait son tit travail et doit renvoyer le resultat le probleme c qu'il me faudrai une maniere pour ke le processeur principal recoive le resultat mais sans savoir qui le revoie??

je c po si j'ai été clair mais je ne trouve pas de solution

merci pour ta reponse.

[fafaro]

Bonjour à tous,

Premièrement, ce thread de discussion est très intéressant et le sujet aurait avantage à devenir un forum et non simplement un thread. Je suis nouveau sur MPI-2 et j'avoue chercher de bonnes références pour me débrouiller.

Salut :)

Je suis très content de voir que le sujet intéresse quelques personnes, mais il faut bien reconnaître que nous sommes peu nombreux.

[...]

Dans info, wdir définit le répertoire de travail du process fils. Ainsi, le chemin relatif devrait fonctionner. Dans argv, il y a le nom du fichier de configuration à ouvrir. Ce que j'observe c'est que le processus fils est correctement appellé (j'ai affiché les arguments du main pour vérifier), mais l'ouverture du fichier de configuration échoue.

Est-ce que quelqu'un peut m'éclairer? Merci à l'avance

Sais-tu si les processus créés par le "spawn" reçoivent bien les arguments ? Si ils reçoivent correctement les arguments, deux autres questions : as-tu un système de fichiers commun à tous les processeurs que tu utilises pour ton application parallèle (montage NFS typiquement) et le problème disparaît-il avec un chemin absolu vers le fichier de configuration ?

[fafaro]

Salut !

Donc j'ai un tit probleme avec MPI je doit fair une methode de tri en parrallellisation donc j'envoie le tableau avec MPI_Send lautre processeur fait son tit travail et doit renvoyer le resultat le probleme c qu'il me faudrai une maniere pour ke le processeur principal recoive le resultat mais sans savoir qui le revoie??

je c po si j'ai été clair mais je ne trouve pas de solution

merci pour ta reponse.

Bonjour,

Deux possibilités différentes :

- si tu utilises des communications point à point (entre un processus A et un processus B), lorsque que tu utilises MPI_Recv (ou un équivalent comme IRecv, BRecv) tu peux utiliser MPI_ANY_SOURCE comme rang de processus émetteur ; dans ce cas, le processus receveur n'examinera pas le rang de l'émetteur ;

- si tu utilises des communications collectives pour que plusieurs processus envoient le résultat de leur tri local à un autre, alors le rang des processus émetteur importe peu, le seul qui soit important est le rang du processus qui reçoit (regarde ce que j'ai écrit sur les communications collectives).

[fernyqc]

Sais-tu si les processus créés par le "spawn" reçoivent bien les arguments ? Si ils reçoivent correctement les arguments, deux autres questions : as-tu un système de fichiers commun à tous les processeurs que tu utilises pour ton application parallèle (montage NFS typiquement) et le problème disparaît-il avec un chemin absolu vers le fichier de configuration ?

Les processus créées par le spawn reçoivent bel et bien les arguments. Le problème ne disparait pas avec un chemin absolu sur le fichier de configuration. Le système de fichier est le même puisque le processus est lancé sur le même noeud de calcul.