elsA Couplage elsA/ens++ à l`aide du logiciel PALM (Note Technique )

Transcription

elsA
DSNA
Couplage elsA/ens++ à l’aide du logiciel
PALM
Réf.: /ELSA/??
Date : ((6 juillet 2004))
Page :
1 / 27
Couplage elsA/ens++ à l’aide du logiciel PALM
(Note Technique )
Objet : couplage multi-disciplinaire
Qualité
Rédacteur(s)
Nom(s)
Frieder Loercher
Diffusion : Voir page en annexe
DTP MODELES DE DONNEES AERODYNAMIQUES
Réf.: /ELSA/??
Page :
2 / 27
elsA
PALM
DSNA
Couplage d’elsA à l’aide de PALM
1.
Introduction
Le logiciel PALM (Projet d’Assimilation par Logiciel Multi méthode), developpé au CERFACS
(www.cerfacs.fr/~palm), permet de coupler plusieurs applications, éventuellement parallélisées
via MPI ou OpenMP elles-mêmes.
Les applications couplées avec PALM peuvent entre autres échanger des données aisément. PALM
gère le rassemblement de champs de données d’une application distribuée sur plusieurs processeurs dans un champs global ainsi que la redistribution sur une autre configuration de processeurs
utilisée par une autre application.
Cette note décrit dans les Sections 2 à 8 une approche générale de l’utilisation de PALM avec
elsA. Des applications que l’on pourrait coupler à elsA peuvent être par exemple :
– une application de contrôle qui recoit en permanence pendant un calcul d’elsA des données
elsA afin de fournir à l’utilisateur l’état du calcul ou des résultats intermédiaires. De plus, une
telle application pourrait indiquer à elsA de terminer son calcul (par exemple, si un critère
d’arrêt est atteint).
– des applications multiphysiques en aéroelasticité, aérothermique, aéroacoustique.
L’ONERA a déjà experimenté ce type de couplage avec l’outil CALCIUM d’EDF dans le cadre du
projet ARCAE.
Dans le cadre de ce travail, une application a été réalisée qui couple les logiciels elsA, ENS++ et
elsa_damas et qui a les fonctionalités suivantes:
– elle permet de mettre à jour en permanence une base de données damas, pendant un calcul
d’elsA utilisant plusieurs processeurs, avec des résultats préliminaires d’elsA.
– elle permet d’effectuer des post-traitements ENS++ à intervalles réguliers avec des résultats
préliminaires d’un calcul d’elsA (par exemple, calculer de coupes de ρ à intervalle régulier).
– elle permet d’effectuer, pendant un calcul elsA, en parallèle des post-traitements ENS++ des résultats préliminaires et d’arrêter le calcul elsA si les résultats du post-traitement correspondent
à un critère d’arrr̂et (par exemple, si une variable calculée par ENS++ a convergé).
Les Sections 9 à 13 décrivent précisément cette application particulière.
a été couplé avec succès sur les machines Compaq Alpha du CERFACS et SUN SOLARIS5.9 du CERFACS et les IBM Power3 et Power4 du CINES.
elsA
Sur les machines Power3 et Power4, des problèmes ont été rencontrés dûs au fait qu’elsA utilise des librairies partagées. Un couplage elsA PALM nécessite que elsA soit compilé en mode
statique (sur IBM).
2.
PALM (Projet d’Assimilation par Logiciel Multi méthode)
Il existe deux versions principales de PALM: PALM_research et PALM_MP. La version la plus
récente est PALM_MP. Ce document est basé uniquement sur une utilisation de PALM_MP. Les
elsA
PALM
DSNA
Réf.: /ELSA/??
Page :
3 / 27
avantages principaux de PALM_MP par rapport à PALM_research sont:
– PALM_MP est basé sur le modèle MPMD (Multiple Process Multiple Data), alors que PALM_research
est basé sur le modèle SPMD (Singe Process Multiple Data) émulant du MPMD. En pratique,
cela veut dire que, pour les différentes applications couplées, différents fichiers exécutables
sont créés (PALM_research: un exécutable global est généré qui est, pendant l’exécution, chargée entièrement sur tous les processeurs).
– PALM_MP supporte le Fortran, le C et le C++ (alors que PALM_research supporte seulement
le Fortran).
– dans le futur, PALM_MP implémentera des objets de taille dynamique (jusqu’à présent, il
faut figer les tailles des champs d’échange de données au moment de la compilation finale
de l’application PALM). Comme elsA utilise des champs de taille dynamique, cela sera d’un
grand interêt.
Il est recommandé de bien se former à PALM avant de travailler sur le couplage PALM - elsA.
Il existe de bons tutoriels, et après trois jours de formation, on a acquis les bases fondamentales
pour un travailler avec PALM.
3. Que faut-il faire pour coupler une application avec PALM?
1. s’assurer de la disponibilié des fonctionalités du standard MPI2 sur la machine cible (nécessitées par PALM_MP).
2. installer le logiciel PALM_MP sur la machine cible.
3. pour chaque application (une application est appelée unité dans l’environnement PALM) , donner un certain nombre d’informations dans une "carte d’identité" (Nom de l’unité, nombre de
processeurs de l’unité, taille des champs de données à envoyer et à recevoir, distribution des
données sur les processeurs, nom des fichiers à compiler, nom de la fonction à appeler).
4. changer le nom de la fonction main de l’application dans le nom de la fonction à appeler décrit
dans la carte d’identité. (Pour les unités Fortran: changer le mot clé PROGRAM dans l’unité en
SUBROUTINE.)
5. enlever dans l’application les appels à MPI_Init et MPI_Finalize.
6. remplacer le communicateur MPI_COMM_WORLD par la variable PALM PL_COMM_EXEC.
Note: pour pouvoir utiliser la constante PL_COMM_EXEC, il faut inclure un fichier d’entête,
palmlib.h pour des unités en Fortran et palmlibc.h pour les unités en C ou C++.
7. PALM_Put et PALM_Get aux endroits où on veut envoyer ou recevoir des données d’une unité
couplée.
8. définir, à l’aide du logiciel PrePALM, l’enchaînement des unités et les liens entre les applications
(déroulement des lancements des unités, descriptions des communications possibles).
9. compiler l’application PALM (y compris la compilation des unités).
10. lancer l’application avec le programme principal qui s’appèle toujours palm_main.
4. Le standard MPI2
MPI2 est un nouveau standard de la parallélisation MPI (voir http://www.mpi-forum.org/docs/mpi-20-html/
Pour une utilisation de PALM_MP, il est nécessaire que ce standard soit disponible. Il ne l’est pas
Réf.: /ELSA/??
Page :
4 / 27
elsA
PALM
DSNA
encore sur plusieurs architectures récentes (Compaq Alpha, SOLARIS5.9, IBM AIX5.1, ...).
Mais il existe, dans le domaine publique, une implémentation gratuite de la norme MPI2 qui
s’appèle lam (www.lam-mpi.org) et qui met à disposition ces fonctionalités. lam est compilable
sur une large gamme d’architectures récentes.
Une application parallélisée avec lam-mpi doit être compilée avec un compilateur particulier (qui
est effectivement le compilateur avec lequel lam a été compilé, légèrement modifié par lam).
Ce compilateur a le nom mpiCC (C++), mpicc (C) ou mpif77 (Fortran 90 et 77) et se trouve dans
le répertoire $LAMHOME/bin, où $LAMHOME est le répertoire d’installation de lam.
Par conséquent, elsA doit être compilé (si lam est utilisé) avec ces compilateurs.
Note: dans les fichiers Fortran d’elsA, il n’y a pas d’appels à des fonctions MPI, donc il suffit
de changer le compilateur C++. Cela change si on veut envoyer des données à partir d’un sousprogramme Fortran (n’a pas Ãl’tÃl’écessaire dans le cadre de nos travaux)
5.
Concept du couplage d’elsA avec PALM
L’approche décrite ici a comme objectif de limiter les modifications dans le logiciel elsA autant
que possible afin de garder une bonne modularité entre elsA, les autres unités à coupler et la zone
de couplage avec des informations qui ne concernent que le couplage.
Pour une utilisation d’elsA dans un cadre PALM, un nouveau suffixe de production a été introduit:
le suffixe _palm.
Les charactéristiques de compilation d’une production _palm sont:
– le mot clé E_PALM est activé pour le compilateur C++.
– deux répertoires de fichiers d’entête liés au couplage avec PALM sont mentionnés pour le
compilateur C++ (il est nécessaire d’inclure des fichiers d’entête de PALM, donc on ajoute les
répertoires où ces fichiers se trouvent à la liste des répertoires où le compilateur C++ cherche
des fichiers d’entête).
– un compilateur C++ adapté est utilisé pour la compilation, voir la Section précédente.
Pendant la compilation, deux variables d’environnement sont utilisées:
– PALMHOME qui contient le chemin d’ une version installée de PALM.
– PALMWORKDIR qui contient le chemin du répertoire de couplage, càd le répertoire où toutes les
informations concernant le couplage sont rassemblées.
A l’aide du mot clé E_PALM, on peut maintenant distinguer, dans le code source, des parties de
codes qui sont prises en compte seulement pour une compilation _palm.
Pour une telle compilation, il faut maintenant:
– changer le nom de la fonction main (dans une unité PALM, la fonction main ne doit pas apparaître).
– enlever tous les MPI_Init et MPI_Finalize
– changer toutes les occurences de MPI_COMM_WORLD par PL_COMM_EXEC (voir Section suivante
pour la réalisation).
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
5 / 27
– appeler les primitives PALM_Put et PALM_Get aux endroits où on veut envoyer et recevoir des
données.
La compilation d’elsA s’arrête après la création du fichier elsA_wrap.o (pas de création d’elsA_wrap.x).
L’édition des liens finale sera effectuée au cours de la compilation de l’application couplée PALM.
La "carte d’identité" de l’unité elsA se trouve dans le répertoire du couplage (un répertoire qui
n’est pas logiquement un sous-répertoire d’elsA). Dans ce répertoire, il y a aussi tous les fichiers
qui décrivent la configuration de l’application PALM avec toutes les communications possibles
ainsi que les makefiles de PALM et finalement les exécutables. L’essentiel de ces fichiers est
gérée à l’aide de l’outil prePALM.
Il est recommandé d’utiliser toujours le mot clé _mpi avec le mot clé _palm, car on a identifié des
problèmes en utilisant une version non-MPI d’elsA avec PALM.
Le couplage d’elsA avec PALM a l’inconvénient de supprimer la possibilité de passer les paramètres d’appel de l’application PALM à l’unité elsA. On contourne ce problème via le fichier
utilisé pour décrire la carte d’identité d’elsA où quelques lignes de code cherchent les paramètres
d’appel pour elsA dans un fichier (elsaparams.in) et appellent la fonction main d’elsA (qui ne
s’appele plus main) avec ces paramètres de ligne de commande.
6. Réalisation
Dans cette section, les étapes d’une réalisation possible sont décrites pour un couplage d’elsA à
l’aide de PALM.
1. s’assurer que le système a les capacités de MPI2. Si ce n’est pas le cas, il faut installer un outil
qui s’appele lam sur le système (www.lam-mpi.org). lam doit être compilé avec les mêmes
compilateurs que l’on veut utiliser pour la compilation d’elsA.
Exemple: Si on veut compiler elsA avec le compilateur C++ cxx, il faut compiler lam avec
cxx. Ensuite, lam crée un ”wrapper” mpiCC, qui correspond au compilateur cxx incluant des
modifications lam et qui est à utiliser pour la compilation d’elsA.
2. installer le logiciel PALM_MP.
3. définir le suffixe de production _palm dans $ELSAHOME/Kernel/cfg/MakeMake.mk:
palm)
FLIST="${FLIST} -D___PALM";
PRODMOD="${PRODMODE}_palm";;
4. d’ajouter dans le fichier $ELSAHOME/Kernel/cfg/prods/Make_*.mk correspondant à la machine cible les lignes suivantes:
#ifdef ___PALM
PALMCCCFLAGS=-DE_PALM -I$(PALMHOME)/include -I$(PALMWORKDIR)
E_PALM=yes
#endif
et ajouter, dans le même fichier, $(PALMCCCFLAGS) à la variable E_CCCFLAGS. La variable d’environnement PALMHOME contient le chemin au logiciel PALM, PALMWORKDIR contient le chemin
pour le couplage. Avant la compilation d’elsA, ces variables sont à définir.
5. dans le même fichier, il faut définir les compilateurs utilisés. Pour un couplage elsA-PALM,
avec le logiciel lam, le compilateur C++ à choisir est mpiCC (on peut distinguer entre une
production d’elsA normale et une production à compiler pour une utilisation avec PALM à
l’aide du mot clé ___PALM).
Réf.: /ELSA/??
Page :
6 / 27
elsA
PALM
DSNA
6. modifier dans $ELSAHOME/Kernel/cfg/prods/Make_lib.mk, la règle .o.x:
initiale (I3104f):
@if ($(LD) $(E_SCOPE_LIB) -o $@ $< $(E_ELSALIBS) $(LDFLAGS) $(OTHERLIBS));\
then :; else rm -f $@ ;$(E_ECHOMAKE) " FAILED";fi
changer en:
@if [ x$(E_PALM) = xyes ]; then\
echo $(LD) $(E_SCOPE_LIB) $(ELSAHOME)/Kernel/src/$(E_SYS)/$< $(E_ELSALIBS)\
$(LDFLAGS) $(OTHERLIBS) > $(PALMWORKDIR)/elsalinkflags.in;\
$(E_ECHOMAKE) $@ NOT built. Parameters for linkage indicated\
in $(PALMWORKDIR)/elsalinkflags.in;\
else\
if ($(LD) $(E_SCOPE_LIB) -o $@ $< $(E_ELSALIBS) $(LDFLAGS) $(OTHERLIBS));\
then :; else rm -f $@ ;$(E_ECHOMAKE) " FAILED";fi ;\
fi
Cette modification fait que, pour une production _palm, le fichier elsA_wrap.x n’est pas linké.
Les paramètres du link qui auraient été utilisés sont écrits dans un fichier. Ceux-ci sont nécessaire pour le link final de l’application PALM.
Note: tous les paramètres de linkage étaient écrits dans le fichier elsalinkflags.in sauf le
-o $@. Le nom du fichier finalement linké dans le cadre PALM ne sera pas celui utilisé par
elsA.
7. modifier dans $ELSAHOME/Kernel/src/Api/Make_obj.mk, le target api:
initial (v3104f):
@$(E_ECHOMAKE) " Symlink exec to " $(E_PRODDIR)/$(E_EXECNAME)
@(cd $(E_PRODDIR); ln -sf Wrapper/elsA_wrap.x $(E_EXECNAME) 2>/dev/null)
@$(E_ECHOMAKE) " Done"
changé en:
@if [ x$(E_PALM) =
$(E_ECHOMAKE) "
(cd $(E_PRODDIR);
fi
@$(E_ECHOMAKE) "
xyes ]; then :; else\
Symlink exec to " $(E_PRODDIR)/$(E_EXECNAME);\
ln -sf Wrapper/elsA_wrap.x $(E_EXECNAME) 2>/dev/null);\
Done"
Comme pour une production _palm le fichier elsA_wrap.x n’est pas linké, on ne fait pas non
plus un lien symbolique sur ce fichier.
8. mettre des #ifdef E_PALM devant toutes les occurences de MPI_Init et MPI_FINALIZE dans
le code source d’elsA (et des #endif après ces occurences). Toutes les occurences sont centralisées dans le fichier /src/Pcm/Base/PcmTaskMPI.C.
9. ajouter, dans le fichier $ELSAHOME/Kernel/src/Pcm/Base/PcmDefMpi.h, après la ligne #include <mpi.h>,
les lignes:
#ifdef E_PALM
#undef MPI_COMM_WORLD
#define MPI_COMM_WORLD PL_COMM_EXEC
#endif
Cela remplace la constante MPI_COMM_WORLD dans tout le code par PL_COMM_EXEC. Il faut donc
inclure dans ce fichier (PcmDefMpi.h) le fichier palmlibc.h.
Note: à partir de la version 3104f, le fichier mpi.h est uniquement inclu dans PcmDefMpi.h.
Donc, ce mécanisme fonctionne seulement à partir de cette version d’elsA.
10. changer dans /src/Api/Wrapper/elsA_wrap.C la ligne:
int main(int argc, char **argv)
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
7 / 27
en:
#ifdef E_PALM
int progelsa(int argc, char **argv)
#else
int main(int argc, char **argv)
#endif
Note: le nom progelsa est choisi arbitrairement; cette fonction est appelée par une autre fonc-
tion encore à définir dans le répertoire du couplage.
11. ici, le procédé pour chaque envoi ou reception de données est décrit. Si l’on veut envoyer/recevoir
des données dans un "fichier" C++, il faut tout d’abord déclarer l’inclusion des fichiers:
#include "palmlibc.h"
#include "palm_user_paramc.h" //pour des constantes utilisateur dans PALM
Maintenant, il est possible d’appeler PALM_Put resp. PALM_Get de n’importe quel endroit dans
ce fichier. Pour pouvoir compiler tout cela aussi pour une production elsA sans PALM, il est
pratique de mettre tout les instructions spécifique à PALM dans des #ifdef E_PALM-régions.
12. avant une compilation d’elsA, il faut définir les deux variables d’environnement utilisées dans
les fichiers make: $PALMHOME contient le chemin au logiciel PALM, les fichiers include se
trouvent dans $PALMHOME/include et les librairies dans $PALMHOME/lib. $PALMWORKDIR contient
dans le répertoire du couplage; ici le compilateur trouve le fichier palm_user_param.h dans
lequel les constantes d’utilisateur au niveau de PALM sont définites.
13. créer, dans le répertoire de couplage, un fichier .C avec la carte d’identité d’elsA et la fonction qui appele elsA (donc qui appele progelsa() dans cet exemple). Cette fonction simule
aussi des paramètres d’appel à elsA. Ce fichier se présente, au minimum (sans communications
décrites), comme suit:
/*PALM_UNIT -name elsA\
-functions {C++ call_elsa}\
-object_files {unit_elsA.o}\
-parallel mpi\
-minproc 1\
-maxproc 1\
-comment {elsA caller}
*/
extern int progelsa(int argc, char ** argv);
#include <ifstream.h>
#include <iostream.h>
extern "C" void call_elsa_(void)
{
ifstream infile;
infile.open("elsaparams.in");
char argline[1000];
infile.getline(argline,1000,’\n’);
infile.close();
int i=0;
int argc_=1;
char * ptr[20];
while(argline[i]!=0)
{
Réf.: /ELSA/??
Page :
8 / 27
elsA
PALM
DSNA
if (((i==0)||(argline[i]==’ ’)) && (argline[i+1] != ’ ’)
&& (argline[i+1] != ’\n’) && (argline[i+1] != 0)
&& (argline[i+1] != ’\t’))
{
if (i==0) ptr[argc_]=&(argline[i]);
else
{
argline[i]=0;
ptr[argc_]=&(argline[i+1]);
}
argc_++;
}
i++;
}
char nullarg[20]="main_block_1";
ptr[0]=nullarg;
char ** argv_;
argv_ = ptr;
cout << "NOW CALLING ELSA..." << endl;
int result=progelsa(argc_,argv_);
cout << "ELSA returns: " << result << endl;
}
Ici, la carte d’identité est constituée seulement de la description de l’unité elsA, avec seulement
un processeur. Dans cette carte d’identité, l’attribut functions, qui est affecté par call_elsa
est définie comme la fonction à appeler par PALM lors d’un appel de l’unité elsA. PALM
réserve dans ce cas 1 processeur à l’unité elsA.
Le mot clé object_files contient normalement toutes les dépendances de l’unité, mais, il est
trop complexe, dans le cas d’elsA, d’y mentionner tous les .o d’elsA; de plus on veut utiliser
des librairies partagées. Donc, on mentionne ici seulement le fichier objet elsamask.o (pourvu
que le fichier décrit ici soit nommé elsamask.C). Les autres dépendances seront résolues différemment.
La nomenclature extern "C" void call_elsa_(void) est due à une inconsistance dans ma
version de PALM et pourra plus tard être remplacée par extern "C" void call_elsa(void).
La fonction call_elsa_ appele simplement la fonction progelsa, qui est en fait la fonction
main d’elsA (avec le nom modifié.). De plus, call_elsa_ cherche des paramètres de la ligne
de commande qu’il faut donner à elsA dans le fichier elsaparams.in et les fourni à progelsa.
Note: le nom de l’exécutable est mis dans argv_[0]. Sur IBM, il est absolument nécessaire de
bien le faire, sinon on obtient des erreurs difficile à identifier.
14. arrivé à ce stade, il faudrait aussi décrire les cartes d’identités des autres unités (i.e. les applications couplées à elsA). La marche à suivre pour une application couplée à elsA est équivalente
à celle utilisée pour elsA.
15. définir, à l’aide du logiciel prePALM, le déroulement de l’application couplée et toutes les communications possibles puis création des fichiers PALM.
16. dans le fichier Makefile créé par prePALM, il faut ajouter, à la commande du linkage du programme qui correspond à elsA, les paramètres de linkage obtenus par la commande make api
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
9 / 27
(y compris les librairies d’elsA et elsA_wrap.o). Il est strictement conseillé d’utiliser vraiment CES paramètres et de ne pas construire un lot de paramètres par main. On a réalisé cela
en ajoutant au bon endroit ‘sed -e "s/[^ ]* //" elsalinkflags.mak‘.
Note: à l’exécution de la règle make api, les paramètres de linkage d’elsA étaient écrits dans
ce fichier. Le premier mot doit être enlevé à l’aide de sed, puisqu’il s’agit du compilateur
lui-même.
Note: on peut sans problème décrire une dépendance dans ce Makefile qui compile automatiquement le make elsa si nécessaire.
Note: si on crée, dans la suite, à nouveau des fichiers à l’aide de PrePALM (suite à une modification...) , il faut faire attention de ne pas supprimer les modifications qui ont été faites dans
ce Makefile. Le Makefile doit normalement seulement être modifié si de nouvelles unités sont
ajoutées dans l’application PALM.
17. compilation d’elsA et des autres unités.
18. si tout s’est bien passé, un make dans le répertoire de couplage crée l’application couplée
PALM. Pour la lancer, il faut lancer l’exécutable palm_main.
7. Descriptions des fonctionalités intégrés à partir de I3107e
Les points de 3 à 10 de la section précédente sont intégrés dans elsA à partir de la version I3107e.
De plus, l’envoi de données d’elsA est facilité à l’aide d’un nouveau format d’extraction qui
s’appele palm. Un objet d’extraction avec ce format envoie les données à une interface PALM au
lieu de les écrire dans un fichier, comme pour les autre formats. Les données envoyées par un objet
d’extraction PALM sont toujours précédées par quelques informations concernant les données qui
viennent dans la suite.
Ce format d’extraction palm est réalisé notamment dans les deux fichiers Sio/Access/SioAccessPALM.h
et Sio/Access/SioAccessPALM.C. La nouvelle classe créée dans ces fichiers se comporte similairement aux autres classes de format d’extraction, sauf que les données sont envoyées à une
interface PALM au lieu d’un fichier.
Note: le format palm fonctionne seulement pour des extractions de données, et non pas pour
une importation de données, par exemple de maillages. Cette dernière fonctionalité pourrait être
ajoutée très facilement si besoin est.
Les données sont toujours envoyées dans le format double de C++. Pour le format du header
envoyé avant les données, voir le fichier Sio/Access/SioAccessPALM.C. Les informations que
l’on veut envoyer avant les données sont éventuellement à adapter à l’application couplée.
Un objet d’extraction PALM donne aux paquets de données un tag PALM qui identifie le bloc d’où
les données viennent et la variable à laquelle les données correspondent. Ce tag est calculé selon
la formule iBlock*numVars+iVar. iVar est un indice qui correspond à une certaine variable, et
numVars est l’indice le plus grand possible. La correspondance entre le nom de la variable et son
indice est gérée dans le fichier Sio/Access/SioAccessPALM.C.
Pour l’envoi d’un paquet de données, PALM utilise un nom pour spacename et un nom pour
objectname (voir documentation PALM). Le string que l’on donne à un objet d’extraction PALM
avec le mot clé filename dans le script Python est utilisé pour trouver ces deux noms.
Réf.: /ELSA/??
Page :
10 / 27
elsA
PALM
DSNA
Pour les headers, spacename est filename+"headerspace"+ et objectname est filename+"headerobject"+.
Similairement, pour les vraies paquets de données, ces noms sont filename+"dataspace"+ et
filename+"dataobject"+ respectivement.
Il faut donc utiliser le mot clé filename pour les objets d’extraction PALM en correspondance
avec les cartes d’identité de PALM, et en correspondance avec les unités receptrices.
8.
Quelques retours d’expériences
Dans cette section, on décrit quelques expériences utiles.
– dans la version de PALM utilisée, prePALM n’a pas pu lire des cartes d’identité écrites en écriture C++, j’ai donc utilisé l’écriture C (ce qui n’est pas forcément compatible avec le standard
de compilation C++. Ce problème devrait être resolu dans de futures versions de PALM_MP).
– dans la carte d’identité: il faut, avant des paranthèses, toujours mettre un espace, donc par
exemple shape (1) et pas shape(1).
– lire une carte d’identité par prePALM: j’ai constaté qu’une mise à jour d’une carte d’identité
conduit souvent à des inconsistences. Je recommande, pour l’instant, de toujours EFFACER
une unité dans prePALM avant de la recharger. Cela a l’inconvenient que les liens de l’unité sont
perdus et doivent être reconstruits. Ce problème devrait disparaître dans de futures versions de
PALM.
– dans prePALM: mettre TOUTES les instructions, unités etc. dans un bloc.
– contrairement à PALM_research, il faut toujours définir le nombre de processeurs utilisés pour
l’ensemble de l’application PALM. Si un nombre de processeurs trop petit et choisi, PALM peut
essayer d’exécuter plusieur branches en séquentiel, ce qui peut conduire à des "deadlocks" de
communication.
– avant l’exécution de palm_main: lancer le daemon lamboot si nécessaire (si le standard MPI2
n’est pas implanté sur la machine cible). Si un programme utilisant lam ne se termine pas
proprement, il faut appeler lamclean avant de relancer une application lam.
– au moment où on effectue la commande lamboot, l’environnement actuel est exporté aux hosts
de lam. Si on change dans la suite l’environnement actuel (par exemple si on change la version
d’elsA utilisée), ce changement ne sera pas automatiquement pris en compte pour les hosts de
lam. Pour les mettre à jour, il faut faire un lamhalt et un nouveau lamboot.
9.
Un exemple d’application: Le couplage d’elsA, ENS++ et elsa_damas
Les sections suivantes décrivent l’application couplée des trois logiciels elsA, ENS++, et elsadamas
afin de réaliser des post-processings indisponibles dans elsA en cours de calcul (on evite ainsi
d’implanter des fonctionalités ENS++ dans elsA).
Cette application est capable de lancer dans un intervalle quelconque (en itérations d’elsA) soit
le logiciel ENS++, soit le logiciel elsadamas ou bien les deux avec en entrée des résultats préliminaires d’elsA.
De plus, la convergence de plusieurs variables calculées par ENS++ peut être utilisée pour piloter
le comportement d’elsA et notamment son intérruption.
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
11 / 27
10. Rappel: Préparation d’elsA, préparation de ENS++ et elsa_damas
Rappelons les démarches qui sont à effectuer en général si on veut coupler elsA à l’aide de PALM.
1. PALM et l’environnement MPI2 (eventuellement lam) sont installés sur la machine, elsA est
compilé avec un compilateur icompatible avec MPI2. La variable d’environnement PALMHOME
contient le chemin vers une version installée de PALM.
2. dans elsA: Les appels à MPI_Init et MPI_Finalize sont supprimés pour la compilation PALM.
3. le communicateur MPI_COMM_WORLD est remplacé par PL_COMM_EXEC.
4. le nom de la fonction main a été changé en progelsa.
5. un répertoire pour l’application couplée a été créé. La variable d’environnement PALMWORKDIR
contient le chemin vers ce répertoire.
6. le compilateur d’elsA ajoute les chemins PALMHOME et PALMWORKDIR à la liste des répertoires
où il cherche des fichiers d’entête.
7. au lieu d’effectuer le link final de elsA_wrap.x, les paramètres du link final sont écrits dans un
fichier (PALMWORKDIR/elsalinkflags.in).
8. dans PALMWORKDIR, une carte d’identité basique a été créée pour elsA.
Note: à partir de la version d’elsA I3107, les points de 2 à 7 sont déjà réalisés dans elsa pour
une production _palm.
Les logiciels ENS++ et elsa_damas sont à préparer de la même manière. Plus précisement:
– les points 2 à 3 n’ont pas d’importance, puisque ENS++ et elsadamas ne sont pas des logiciels
parallélisés.
– comme dans elsA il faut changer le nom de la fonction main dans ENS++: on la nomme
progens. elsadamas est écrit en Fortran, donc il faut remplacer le mot PROGRAM par SUBROUTINE.
– on ajoute les répertoires PALMHOME et PALMWORKDIR à la liste de répertoires où les compilateurs
C++ et Fortran de ENS++ et elsadamas cherchent des fichiers d’entête.
– comme pour elsA, le link final n’est pas effectué, et les paramètres du link final sont exportés
dans des fichiers (PALMWORKDIR/enslinkflags.in et PALMWORKDIR/elsadamaslinkflags.in).
Note: on a, plus tard, besoin des tous les paramètres de linkage, sauf le linkeur lui-même et
sauf le -o fichier_executable (il ne faut pas écrire ces derniers paramètres dans le fichier).
– pour ENS++ et elsadamas, des cartes d’identité basiques sont créées dans PALMWORKDIR. Exemple
pour ENS++ (fichier unit_ens.cc):
/*PALM_ID_MODE MP*/
/*PALM_UNIT -name ENS\
-functions {C++ call_ens}\
-object\_files {unit_ens.o}\
-comment {unit ENS}
*/
extern int progens(void);
extern "C" void call_ens()
{
int i= progens();
}
elsA
Réf.: /ELSA/??
Page :
12 / 27
11.
PALM
DSNA
Le schéma de l’application couplée
b1
b2
Start ON
b2
4
100
elsA
elsA
b1
100
ENS
ENS
100
end
end
elsA_DAMAS
elsA_DAMAS
b2
Fig. 1 – Schéma de l’application couplée
Le schéma présenté est celui de l’application finale. Il est montré ici afin d’expliquer le déroulement de l’application couplée. L’application est constituée de deux branches (nommées b1 et
b2). La branche b1 est Start On, càd elle est lancée au démarrage de l’application couplée. La
première chose qu’elle fait est le lancement de la branche b2.
Dans chaque branche, il y a un bloc (grande région réctangulaire). Un bloc correspond finalement
à un exécutable. Il est important de mettre tous les actions à l’intérieur d’un bloc.
Les trois unités que l’on voit sont les unités elsA, ENS++ et elsa_damas. Elles correspondent respectivement aux trois logiciels elsA, ENS++ et elsa_damas. L’unité elsA est une unité parallèle,
qui utilise ici 4 processeurs (petit chiffre 4). Le concept permet de facilement modifier ce nombre,
néanmoins, on voit déjà ici qu’il faut fixer le nombre de processeurs pour chaque unité avant la
compilation de l’application couplée. Donc, si on change le nombre de processeurs d’elsA, il est
nécessaire de faire quelques modifications des fichiers de description de l’application PALM.
Les autres unités ne sont pas en parallèle et utilisent seulement un processus.
11.1. Description des échanges de données et informations
L’unité elsA possède cinq communications possibles (slots), dont deux en entrée (cercles du haut)
et trois en sortie (cercles du bas).
La première entrée correspond à un signal qui autorise l’envoi de données d’elsA. Dans cette
application, elsA doit envoyer des données quand la branche réceptrice signale qu’elle est prête.
Donc, avant d’envoyer ses données, elsA envoie un signal signifiant qu’elle est prête (la dernière
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
13 / 27
communication en sortie de l’unité elsA). Ensuite, elsA attend un second signal pour envoyer ses
données (le PALM_Get pour le signal dans elsA attend jusqu’à ce que le signal soit reçu!).
Note: le signal envoyé par elsA contient en plus l’information s’il s’agit de données dans un cadre
"envoi périodique" ou dans un cadre "envoi final" de données (ce qui signifie que ce sont les
données qui sont envoyées après qu’elsA ait terminé le calcul.)
La branche b2 envoie le message qu’elle est prête à recevoir des données tout de suite après avoir
reçu le signal d’elsA. Cependant, elle peut le faire seulement à partir du moment où elle a terminé
toutes les actions d’ENS++ ou elsa_damas et la réception d’un paquet de données envoyé par elsA
antérieurement.
La deuxième entrée d’elsA vient d’un buffer. Ce buffer contient seulement un entier dont la valeur
correspond à un feedback pour elsA. Suivant cette valeur, elsA peut par exemple terminer le calcul
ou effectuer une autre action.
Contrairement à une communication directe, une communication par le buffer ne bloque pas dans
les PALM_Get: La valeur ne disparait pas du buffer après un PALM_Get et peut donc être reçue
plusieurs fois.
La première action effectuée par la branche b2 est le remplissage de ce buffer par une valeur qui
signale à elsA de continuer normalement. Tant que cette valeur n’est pas modifiée, elsA aura
toujours l’ordre de continuer normalement. Dans certaines conditions, comme décrit plus bas, la
valeur dans ce buffer est modifiée en une valeur qui signale à elsA d’arrêter le calcul.
Les deux sorties d’elsA qui restent correspondent à l’envoi de données résultantes du calcul
d’elsA. Il y en a deux parce que toutes les données sont précédées par un paquet d’informations correspondant à la description de ces données. L’envoi de ces paquets se fait en utilisant une
communication directe (avec ENS++ ou elsa_damas), pendant que l’envoi des données se fait ici
via un buffer. On pourrait aussi envoyer les données directement, l’utilisation du buffer résulte des
considérations de performance (si le buffer est utilisé, les données sont stockées seulement une
fois dans la mémoire; sinon elles sont stockées deux fois parce qu’il y a deux envois).
La description détaillée du transfert des données d’elsA est faite dans la Section 11.3.
Les communications à l’intérieur de la branche 2 sont décrites dans la section suivante.
11.2. Description de la branche 2
La branche 2 est un peu plus complexe (notamment contrôle de convergence des variables calculées pas ENS++).
Le code de branche 2 (Figure 2) correspond à ce qu’on voit dans la Figure 1, avec plus de détails,
seulement pour la branche 2.
La branche 2 contrôle le déroulement de l’application (alors que la branche 1 lance seulement
une fois l’unité elsA). Selon les signaux qui viennent d’elsA, il est décidé quelles actions sont à
effectuer dans branche 2: lancement d’ENS++, d’elsa_damas, ou fin du calcul.
La branche 2 contrôle aussi le feedback qui est envoyé à elsA, donc la branche 2 est capable de
signaler à elsA d’arrêter le calcul. Dans l’exemple décrit ici, la branche 2 surveille la convergence
elsA
Réf.: /ELSA/??
Page :
14 / 27
PALM
Declarations
double precision :: FL_TOLERANCE = 0.0001
integer :: FL_MIN_CONFIRMS = 5
integer :: action_code = 0
double precision :: received_value = 0.d0
double precision :: old_value = 0.d0
double precision :: gap
integer :: feedback = 0
integer :: flag = 0
logical :: in_tolerance
integer :: nconfirmed = 0
integer :: ib_do
BEGIN b2
BEGIN BLOCK 2
feedback=FL_CONTINUE
PALM_PUT(one_integer,b2_put_3,PL_NO_TIME,PL_NO_TAG,feedback)
DO ib_do = 1, FL_NVARS_TO_CONVERGE, 1
insert some zeros to the oldvalue buffer...
PALM_PUT(one_double,b2_put_1,PL_NO_TIME,ib_do,received_value)
ENDDO
DO WHILE (action_code .ne. FL_FINAL_DATA)
PALM_GET(one_integer,b2_get_1,PL_NO_TIME,PL_NO_TAG,action_code)
flag=FL_RECEPTION_READY
PALM_PUT(one_integer,b2_put_4,PL_NO_TIME,PL_NO_TAG,flag)
IF (action_code .eq. FL_PERIODICAL_DATA)
ENS
in_tolerance=.true.
DO ib_do = 1, FL_NVARS_TO_CONVERGE, 1
PALM_GET(one_double,b2_get_2,PL_NO_TIME,ib_do,received_value)
PALM_GET(one_double,b2_get_3,PL_NO_TIME,ib_do,old_value)
PALM_PUT(one_double,b2_put_2,PL_NO_TIME,ib_do,received_value)
gap=abs((received_value−old_value)/old_value)
IF (gap .GT. FL_TOLERANCE)
in_tolerance=.false.
ENDIF
ENDDO
IF (in_tolerance)
nconfirmed=nconfirmed+1
ENDIF
IF (.not. in_tolerance)
nconfirmed=0
ENDIF
IF (nconfirmed .GE. FL_MIN_CONFIRMS)
feedback=FL_ELSA_CONVERGED
write(*,*)’Send convergence flag to elsA’
PALM_PUT(one_integer,b2_put_5,PL_NO_TIME,PL_NO_TAG,feedback)
ENDIF
ENDIF
IF (action_code .eq. FL_FINAL_DATA)
elsA_DAMAS
ENDIF
ENDDO
END BLOCK 2
END b2
Fig. 2 – Code de la branche b2
DSNA
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
15 / 27
de plusieurs variables calculées par ENS++, et décide ainsi quand elsA doit s’arrêter.
Afin de pouvoir faire tout cela, quelques variables sont déclarées dans branche 2 (voir Figure 2).
Avec FL_TOLERANCE=0.0001 et FL_MIN_CONFIRMS=5, la branche va signaler à elsA d’arrêter le
calcul au moment où la variation relative de toutes les variables envoyées par ENS++ était inférieur
à 0.0001 (0.01%) pendant 5 évaluations succéssives d’ENS++.
Regardons la Figure 2. Après les déclarations, le buffer pour le feedback à elsA est rempli par la
constante integer global FL_CONTINUE, définie dans PrePALM. Cela signale à elsA de tout simplement continuer normalement le calcul.
Note: dans la suite, quelques constantes comme FL_CONTINUE etc. aparaissent. Ce sont des constantes
qu’il faut définir dans PrePALM. Une fois définies, elles seront connues dans les codes de branches
et dans les unités (à l’aide d’un fichier d’entête qui est inclu, dans les unités en C++, c’est le fichier
palm_user_paramc.h).
Ensuite, un buffer appelé oldvaluebuffer est rempli avec des zéros. Ce buffer contient pour
chaque variable à surveiller la valeur du tour précédent d’ENS++ afin de pouvoir la comparer avec
les nouvelles valeurs obtenues par ENS++. On donne comme tag à chacune de ces variables un
nombre (si on contrôle deux variables, ceux-ci sont les nombres un et deux). PALM garde dans le
buffer pour chaque tag la valeur la plus récemment envoyée au buffer.
Ensuite, la branche 2 entre dans la boucle principale. Dans cette boucle, elle attend toujours un
signal action_code d’elsA. action_code peut être FL_PERIODICAL_DATA ou FL_FINAL_DATA.
Après avoir reçu ce signal, un signal FL_RECEIPTION_READY est envoyé qui donne à elsA l’autorisation d’envoyer des données. Imaginons qu’ENS++ ou elsa_damas n’ont pas encore achevé le
traitement des données d’un tour précédent: la branche deux ne va pas envoyer le FL_RECEIPTION_READY
tout de suite, et elsA sera bloqué pour un certain temps. Pour éviter cela, l’intervalle d’envoi de
données d’elsA à ENS++ doit être augmenté.
Selon la valeur d’action_code, soit ENS++, soit elsa_damas est lancé. Note: il n’y aurait pas de
problème pour les lancer tous les deux l’un après l’autre.
Dans le cas où ENS++ est lancé, la branche 2 recoit après l’exécution de l’unité ENS++ un certain
nombre de variables (celles dont on veut surveiller la convergence). Elle les compare avec les
valeurs obtenues du oldvaluebuffer et met à jour ce buffer avec les nouvelles valeurs.
Selon les résultats de ces comparaisons, le feedbackbuffer peut être mis à FL_ELSA_CONVERGED,
ce qui signale à elsA d’arrêter le calcul. La branche 2 ne s’arrête, dans ce cas, pas encore, mais
attend toujours le signal FL_FINAL_DATA, suivi de données, avant de se terminer.
11.3. Méthode pour gérer l’envoi de données distribuées sur plusieurs processeurs
PALM fourni un mécanisme qui permet de rassembler automatiquement dans un champs global
des données envoyées par plusieurs processus, et de redistribuer ces données pour une autre unité
avec un nombre différent de processus. Ce mécanisme n’est pas utilisé pour le couplage décrit ici,
pour les raisons suivantes:
– PALM utilise l’hypothèse qu’un envoi de données d’un champs global correspond à exactement un PALM_Put sur chaque processus. Or, cette hypothèse ne convient pas à l’envoi de
Réf.: /ELSA/??
Page :
16 / 27
elsA
PALM
DSNA
données dans elsA: la structure du logiciel elsA conduit plutôt à un envoi de données par bloc.
Comme le nombre de blocs par processeur est variable, cela conduit à plusieurs PALM_Put d’un
processus elsA pour un champs global.
– l’utilisation de distributeurs PALM nécessiterait que l’on fixe pour chaque processus la taille de
la part locale du champs global au moment de la compilation de l’application couplée. Comme
cette taille varie de bloc à bloc, cela serait très difficile à réaliser.
– la structure des unités réceptrices (ENS++ et elsa_damas) est plutôt adaptée à une réception de
données bloc par bloc et non pas dans un champs global. Donc le rassemblement de données
de plusieurs blocs dans un grand champs n’a même pas d’interêt.
La solution du problème est simple: chaque processus envoie des données bloc par bloc, et donne
un tag à chaque paquet de données qui permet d’indentifier de quel bloc les informations viennent
et à quelle variable elles correspondent. Si une unité réceptrice veut recevoir des valeurs d’une
certaine variable pour un certain bloc, elle calcule le tag correspondant avec une simple formule
et recoit un paquet de données avec ce tag. Ce mécanisme évite toute utilisation de distributeurs
PALM.
Le seul inconvenient est le fait que l’on ne peut plus utiliser, dans PrePALM, une association automatique. Pour 4 processeurs d’elsA, il faudrait utiliser une association 0:3|0 pour l’envoi de
données. La distribution des objets PALM qui correspondent à l’envoi de données est, coté elsA,
REPLICATED_ON_ALL_PROCS.
11.3.1. Informations supplémentaires pour un paquet de données
Dans l’application décrite ici, chaque paquet de données est précédé par un paquet d’informations
concernant les données. Ces informations contiennent par exemple les dimensions du bloc et le
nom de la variable à laquelle les données correspondent. La structure de ce paquet d’informations
est définie dans le fichier src/Sio/Access/SioAccessPALM.C.
Si nécessaire, d’autres informations peuvent être rajoutées à ce header facilement.
11.3.2. Taille des objets d’échange de données
Dans l’application réalisée, seulement un objet est utilisé pour tous les envois de données; càd que
tous les envois de données ont la même taille.
L’inconvénient principal est le fait qu’on génère un traffic qui est significativement plus élevé que
nécessaire, puisqu’on est obligé de choisir la taille de cet objet assez élevée pour le bloc le plus
grand. De plus, coté récepteur, on est obligé d’allouer, dans tous les cas, un champ qui est assez
grand pour pouvoir contenir le paquet de données à recevoir.
Pour le logiciel PALM, des objets de tailles dynamiques sont prévues dans une prochaine version.
Cette nouvelle capacité permettra d’éviter les inconvénients décrits dans cette section.
12.
Les cartes d’identité complètes
Les communications décrites, les cartes d’identité complètes sont présentées ici.
elsA
PALM
DSNA
Réf.: /ELSA/??
Page :
17 / 27
Pour modifier le code des unités le moins possible, les cartes d’identité ne sont pas ajoutées à des
fichiers source de ces unités. Un nouveau fichier a été créé dans le répertoire PALMWORKDIR pour
chaque unité qui contient la carte d’identité et un petit code qui appele l’unité. Le fait de mettre
une fonction qui appele l’unité intrinsèque entre l’application PALM et le code de l’unité permet
entre autre de fournir des paramètres de la ligne de commande ce qui est nécessaire par exemple
pour elsA.
Les trois fichiers unit_elsa.cc, unit_ens.cc et unit_elsadamas.cc sont définis comme suit:
12.1. unit_elsa.cc
/*PALM_UNIT -name elsA\
-functions {C++ call_elsa}\
-parallel mpi\
-minproc 4\
-maxproc 4\
-object_files {unit_elsA.o}\
-comment {elsA}
*/
/*PALM_SPACE -name flagspace\
-shape(1)\
-element_size PL_INTEGER\
-comment {space used by all flags}
*/
/*PALM_SPACE -name ensdataheaderspace\
-shape(1)\
-element_size 5*PL_INTEGER_SIZE + 20\
-comment {space pour data information header}
*/
/*PALM_SPACE
-name ensdatadataspace\
-shape (100000)\
-element_size PL_DOUBLE_PRECISION\
-comment {space for some real}
*/
/*PALM_OBJECT -name ensdataheaderobject\
-space ensdataheaderspace\
-localisation REPLICATED_ON_ALL_PROCS\
-intent OUT\
-tag ON\
-time OFF\
-comment {object for information header}
*/
/*PALM_OBJECT -name ensdatadataobject\
-space ensdatadataspace\
-tag ON\
-time OFF\
-intent OUT\
-comment {sending data}
*/
/*PALM_OBJECT -name flagobject\
-space flagspace\
Réf.: /ELSA/??
Page :
18 / 27
elsA
PALM
DSNA
-intent INOUT\
-tag OFF\
-time OFF\
-comment {object for controlling inter application}
*/
/*PALM_OBJECT -name feedbackobject\
-space flagspace\
-intent IN\
-tag OFF\
-time OFF\
-comment {object for controlling inter application}
*/
#include <iostream.h>
#include <fstream.h>
extern int progelsa(int argc, char ** argv);
extern "C" void call_elsa(void)
{
//here, the parameters for elsA are read from a file and given to elsa...
ifstream infile;
infile.open("elsaparams.in");
char argline[1000];
infile.getline(argline,1000,’\n’);
infile.close();
int i=0;
int argc_=1;
char * ptr[20];
while(argline[i]!=0)
{
if (((i==0)||(argline[i]==’ ’)) && (argline[i+1] != ’ ’)
&& (argline[i+1] != ’\n’) && (argline[i+1] != 0)
&& (argline[i+1] != ’\t’))
{
if (i==0) ptr[argc_]=&(argline[i]);
else
{
argline[i]=0;
ptr[argc_]=&(argline[i+1]);
}
argc_++;
}
i++;
}
char nullarg[20]="mainblock_1";
ptr[0]=nullarg;
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
19 / 27
char ** argv_;
argv_ = ptr;
cout << "NOW CALLING ELSA..." << endl;
int result=progelsa(argc_,argv_);
cout << "ELSA returns: " << result << endl;
}
Comme la taille de ensdatadataspace est choisie à 100000 ici, le bloc le plus grand ne doit pas
être plus grand que 100000 points. De plus, le nombre de processeurs utilisés par elsA est fixé
ici! Si on veut changer une des deux grandeurs, il faut le faire dans ce fichier (et dans toutes les
autres cartes d’identité si on change la taille des messages), ensuite charger ces nouvelles cartes
d’identité dans PrePALM, adapter les associations et faire les compilations.
Note: sur le IBM, il s’est avéré impératif de donner le bon argv[0] à elsA, qui doit contenir le nom
de l’exécutable (main_block_1 dans cet exemple)!
12.2. unit_ens.cc
/*PALM_ID_MODE MP*/
/*PALM_UNIT -name ENS\
-functions {C++ call_ens}\
-object_files {unit_ens.o}\
-comment {unit ENS}
*/
-shape(1)\
*/
/*PALM_SPACE
-shape (100000)\
*/
/*PALM_SPACE -name convergedataspace\
-spape (1)\
-comment {space for convergence variables}
*/
-intent IN\
-tag ON\
-time OFF\
*/
-tag ON\
Réf.: /ELSA/??
Page :
20 / 27
elsA
PALM
DSNA
-time OFF\
-intent IN\
-comment {receiving elsa data}
*/
/*PALM_OBJECT -name convergedataobject\
-space convergedataspace\
-intent OUT\
-tag ON\
-time OFF\
-comment {object for sending a variable value (for convergence tests)}
*/
extern int progens(void);
extern "C" void call_ens()
{
int i= progens();
}
12.3. unit_elsadamas.cc
/*PALM_ID_MODE MP*/
/*PALM_UNIT -name elsA_DAMAS\
-functions {C++ call_elsadamas}\
-object_files {unit_elsadamas.o}\
-comment {unit elsA-DAMAS}
*/
-shape(1)\
*/
/*PALM_SPACE
-shape (100000)\
*/
-intent IN\
-tag ON\
-time OFF\
*/
-tag ON\
-time OFF\
-intent IN\
-comment {receiving elsa data}
*/
extern "C" void elsa_damas_(void);
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
21 / 27
extern "C" void call_elsadamas()
{
elsa_damas_();
}
13. Emplacement des actions PALM dans les unités
Les communications PALM de l’application couplée ont été décrites dans la Section 11.1. Le
problème qui reste à résoudre est: où, dans elsA et les autres unités, faut-il placer les PALM_Put et
PALM_Get pour le bon déroulement de l’application?
13.1. Modifications PALM dans elsA
L’unité elsA a le plus de communications des toutes les unités. Il y en a 5:
1.
2.
3.
4.
5.
envoi du signal qu’elsA veut emettre des données.
reception du signal que la branche 2 est prête à recevoir des données.
reception du flag qui constitue un feedback à elsa.
envoi des paquets d’informations précédants les données.
les blocs de données.
Les communications 1 et 2 se déroulent toujours l’une après l’autre aux mêmes endroits. Il y
a deux endroits où ces deux communications sont effectuées. Tous les deux se trouvent dans
le fichier SioApi.C; un dans extract() et un dans finalExtract(). La différence entre les
deux est que, dans extract(), le signal FL_PERIODICAL_DATA est envoyé, pendant que dans
finalExtracti(), le signal FL_FINAL_DATA est émis.
Dans tous les deux cas, le signal est envoyé si au moins une extraction est effectivement à faire.
C’est à dire que l’hypothèse est toujours faite que si au moins une extraction est effectuée pour une
itération, les envois des données à PALM sont faits. Après avoir envoyé le signal FL_PERIODICAL_DATA
resp. FL_FINAL_DATA, elsA attend le signal FL_RECEPTION_READY avant de continuer. Le signal
qui signifie qu’elsA cherche à envoyer des données est envoyé seulement par le processus 0
d’elsA, pendant que le signal qui signifie que la branche réceptrice est prête à recevoir et reçu
par tous les processus d’elsA: il est très important que tous les processus soient bloqués jusqu’à
ce que la branche receptrice puisse recevoir des données.
La récupération du feedback est effectuée dans le fichier TmoDriver_2.C dans computeSteadyFlow
avant l’appel à sioExtract(). Si le flag est égal à FL_ELSA_CONVERGED, la fonction notifyConvergence()
est appelée.
Les PALM_Put correspondants aux communications 4 et 5 sont placés dans le submodule SioAccess.
Une SioAccess classe a été créée qui envoie des données avec un PALM_Put au lieu de les écrire
dans un fichier. Les données sont toujours précédées par un paquet d’informations. Cette classe est
intégrée dans elsA à partir de la version I3107. Pour envoyer des données à une interface PALM,
il faut donner comme format d’extraction dans le script Python d’elsA le mot clé palm. Pour la
construction des noms des space et object, le string donné avec le mot clé filename est utilisé:
Réf.: /ELSA/??
Page :
22 / 27
elsA
PALM
DSNA
Pour le header, c’est filename + "headerspace" et filename + "headerobject" et pour les
données, c’est filename + "dataspace" et filename + "dataobject".
13.2. Modifications PALM dans elsa_damas
Dans elsa_damas, il y a deux PALM_Get: pour le header des données et pour les données ellesmêmes.
Le mode de fonctionnement d’elsa_damas a été légèrement modifié par rapport à la version
originale.
D’abord, les paramètres pour elsa_damas ne sont plus lus interactivement depuis l’entrée standard, mais depuis un fichier (dans une application couplée, l’utilisation des entrées en interactif
n’est pas possible).
Au lieu de chercher des fichiers et de récuperer les données des fichiers, elsa_damas cherche
maintenant les données d’une interface PALM. elsa_damas fait des PALM_Get pour toutes les
variables et blocs qu’il est sensé recevoir. Il est codé en dur dans elsa_damas quelles variables et
blocs sont à recevoir dans elsa_damas, et elsa_damas balaie tous les tags PALM correspondants
en recevant les données.
Note: la communication entre elsA et elsa_damas est seulement réalisée pour des variables sur
les cellules des blocs entiers et non pas pour des variables aux surfaces (comme par exemple
la friction). L’envoi des variables aux surfaces nécessiterait un mécanisme plus sophistiqué pour
trouver des tags PALM (pour les blocs, le tag PALM est trouvé à l’aide de l’indice du bloc, mais
il n’existe pas d’indice pour les surfaces).
13.3. Modifications PALM dans ENS++
Pour pouvoir utiliser ENS++ dans une application couplée, il fallait d’abord faire une modification
dans ept.C : Au lieu de chercher des commandes dans le stream stdin, on les cherche dans un
filestream, qui ouvre, pour chaque appel à ENS++, le fichier avec le script ENS++. Ceci est nécessaire
puisqu’il n’est pas pratique d’utiliser le stdin dans le cadre d’une application couplée.
Dans ENS++, il y a trois actions PALM: réceptions des headers et réceptions des données, et envoi
des variables dont la convergence est surveillée.
Toutes les autres informations sont toujours obtenues de la base DAMAS, donc celle-là doit être
disponible.
Les données (et les headers) sont reçus dans le fichier getblockvar.f, au lieu de les lire dans la
base DAMAS. Il faut de plus assurer le bon traitement de cellules fictives.
L’envoi des variables à surveiller se fait dans le fichier writescalar.f. Les variables écrites dans
le ’fichier’ palm (selon le script ENS++) ne sont pas effectivement écrites dans ce fichier, mais
envoyées avec un PALM_Put à l’interface PALM.
Il faut qu’un tag PALM soit donné à chaque variable envoyée par ENS++: A la première variable,
c’est le tag 1, à la deuxième le tag 2 etc. Comme la fonction writescalar peut être appelée
plusieurs fois, le problème du tag est résolu à l’aide d’une variable COMMON, qui est initialisée à 1
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
23 / 27
dans la fonction openmodel et qui est incrémentée de 1 après chaque envoi d’une variable à une
interface PALM.
Réf.: /ELSA/??
Page :
24 / 27
elsA
PALM
Page sans texte
DSNA
elsA
DSNA
PALM
Réf.: /ELSA/??
Page :
25 / 27
14. *
Index
Réf.: /ELSA/??
Page :
26 / 27
elsA
PALM
Page sans texte
DSNA
elsA
PALM
DSNA
Réf.: /ELSA/??
Page :
27 / 27
DIFFUSION TYPE
Archives Secrétariat
Rédacteurs
Développeurs elsA
Utilisateurs elsA
Responsable Documentation
FIN de LISTE
Réf.: /ELSA/??
Page :
28 / 27
elsA
PALM
DSNA

elsA Couplage elsA/ens++ à l`aide du logiciel PALM (Note Technique )

Transcription

Documents pareils

ELSA FAYER… EGERIE WATERBIKE

Boite Elsa

fiche de poste pour un/e animateur/trice d`ateliers d`eveil aux langues

PALM BEACH CONVOCATION

PV du 8 Octobre 2014 - Association des Étudiants en Droit de l

Liste des actions menées dans le Rhône

Compte rendu championnat de France Badminton.

Devoir sur table de type Bac : quelles missions pour