Département de physique
Université de Sherbrooke
Printemps 1996
La parallélisation du programme de simulation Monte Carlo quantique (MCQ) a comme objectif principal de permettre le fonctionnement de l'algorithme sur l'ordinateur parallèle SP2 de l'Université de Sherbrooke ceci, afin d'accroître les possibilités de calculs (en rapidité et en quantité). Ce rapport a pour but de faire le point sur la parallélisation du programme de simulation MCQ ainsi que d'expliquer le fonctionnement de la dernière version parallèle du programme. Ce rapport contient trois sections: une première section où sont reportés tous les changements qui ont été faits dans la version séquentielle du programme, une deuxième où l'on explique la procédure de démarrage d'une simulation sur l'ordinateur parallèle SP2 et enfin, une troisième où l'on rend compte de la construction du programme de statistiques implanté afin de recueillir les résultats d'une simulation effectuée sur le SP2.
1- Distribuer à chaque noeuds, dont le nombre est indiqué dans le fichier soum de soumission (cf.
paragraphe 2.1), une copie du programme à exécuter.
2- Réorienter les entrées/sorties principalement en attribuant des fichiers d'entrées différents pour chaque
noeuds en plus de les désigner en unités par défaut, i.e. par la désignation '*'.
La première tâche est exécutée par la portion suivante du script:
... # setenv JID `/prog/SP_Scheduler/getjid` setenv MP_EUILIB us setenv TMP_HOSTFILE $HOME/SPnodes.$JID setenv HOSTFILE $HOME/.SPnodes. setenv MP_PROCS 1 setenv MP_INFOLEVEL 0 setenv LANG En_US # # script variables # setenv PROG $1 setenv WORKINGDIR $2 setenv INPUTFILE $3 setenv OUTPUTFILE $4 # ... cd $WORKINGDIR # @ num = 0 foreach host (`cat $TMP_HOSTFILE`) setenv MP_HOSTFILE $HOSTFILE.$num echo $host >! $MP_HOSTFILE echo "On node: "`cat $MP_HOSTFILE` echo "Input/output: "$num poe $PROG < $INPUTFILE.$num >! $OUTPUTFILE.$num & @ num = $num + 1 end ...Le premier groupe de commandes déclare les variables de paramètres tels que le nombre de noeuds, etc. tandis que le deuxième groupe ouvre le répertoire où se trouve le programme et démarre ce programme en spécifiant le fichier d'entrée pour chaque noeud.
'PRÉFIXE_ENTRÉE.#'où le préfixe est donné dans le fichier soum et où '# =0...n' est le n du noeud. Ce numéro est assigné par le script selon l'emplacement du noeud. Par exemple, si le préfixe donné dans le fichier soum est
'/home/htouchet/tampin'et que dans le fichier soum nous avons demandé quatre noeuds (n=4) alors, le script assignera comme fichier d'entrée
'/home/htouchet/tampin.0'au noeud 0,
'/home/htouchet/tampin.1'au noeud 1, etc., jusqu'à
'/home/htouchet/tampin.3'pour le dernier noeud. À noter que les fichiers
'/home/htouchet/tampin.0...n'doivent résider dans le répertoire spécifié et être sauvés avec le suffixe numéral sur le disque principal du SP2, i.e celui accessible à partir de aix1 ou tout autre station aix. La lecture d'un de ces fichiers par un noeud se fait comme d'habitude par la commande
READexcepté que l'on désigne ces fichiers par le symbole '*' représentant l'unité par défaut. Comme conséquence, l'emploi des commandes
OPENet
CLOSEn'est plus necessaire sauf bien sûr si on ne fait pas référence à ces fichiers particuliers dits 'd'entrée primaires'.
Les sorties se font de la même façon: chaque noeud enregistre ses résultats dans un fichier de sortie
'PRÉFIXE_SORTIE.#'dont le préfixe a été préalablement spécifié dans le fichier soum. Le script assigne le suffixe numéral # selon la provenance des résultats. Le fait que l'unité par défaut soit maintenant le disque exige la suppression de toutes les sorties à l'écran du programme original de simulation. La description de la gestion des fichiers faite ci-dessus ne concerne que la gestion des entrées primaires désignant les premiers fichiers de lecture soumis au programme. Une description plus détaillée de la structure de tous les fichiers est présentée dans la section 2.3.
Finalement, si l'on résume les modifications à faire dans un programme séquentiel afin de l'utiliser sur le SP2 par l'entremise du script, nous devons:
1- Éliminer toutes les sorties à l'écran.
2- Remplacer toutes les unités d'entrée primaire (cf. 2.3) par l'unité par défaut '*' désignant les premiers
fichiers d'entrée disponibles (un par noeud) pour chaque noeud.
3- Éliminer toutes les commandes OPEN et CLOSE à moins que ces dernières ne concernent des unités
autres que l'unité d'entrée primaire.
1 15 4 b m u /home/htouchet/montec/monteh3.script progch3.out /home/htouchet/montec/ tampin diary s # # Description des lignes precedentes (a changer au besoin): # # 1: compte no. 1 # 20: temps max: 20 minutes # 4: avec 4 processeurs # b: travail "batch" # m: bibliotheque de communication MPL # u: utilisation du commutateur en mode "user space" # /home/cfoisy/cacpus/test/monte.script: nom du fichier script # myprog cacpus/test input output: arguments du script monte.script # myprog: nom de l'executable sequentiel # cacpus/test: repertoire ou reside l'executable, les fichiers d'E/S # input: nom du fichier d'entree # Output: nom du fichier de sortie # s: pour (s)oumissionLes six premières données concernent des paramètres de l'environnement SP2 comme le numéro de compte de l'utilisateur, le temps maximal d'utilisation, le nombres de noeuds, etc. À noter que le temps indiqué constitue une borne maximale de temps d'utilisation. Le deux autres lignes contiennent toute l'information nécessaire à la gestion des entrées/sorties. Premièrement, on a le nom complet du fichier du script de départ sur la première ligne de texte et ensuite, on a dans l'ordre: le nom du fichier exécutable du programme de simulation, le répertoire où réside cet exécutable et les fichiers d'entrées/sorties puis enfin, les préfixes des fichiers primaires d'entrée et ceux de sortie. Il est conseillé de placer tous les fichiers de travail dans le même répertoire.
Le démarrage d'une simulation se fait comme suit:
1- On change les paramètres du fichier soum selon les besoins.
2- Au 'prompt' unix, on tape:
spsubmit < 'NOM DU FICHIER DE SOUMISSION'On voit alors défiler toute une série de questions répondues par les premières données du fichier de soumission. Suite à cela, le programme est lancé sur le SP2. Pour afficher la liste des utilisateurs de l'ordinateur parallèle ainsi que les noms des programmes lancés, on peut utiliser la commande
spqLa liste obtenue par cette commande inclut aussi le numéro d'identification des programmes lancés sur le SP2. Ce numéro est necessaire,entre autres, si l'on désire abandonner l'exécution d'un programme. La ligne de commande à faire dans ce cas est:
sprelease '#identification'.Il est à noter que le SP2 génère des fichiers 'SP....nodes' et 'SW.... nodes' dans notre répertoire pendant l'exécution des programmes. Ces fichiers ne sont d'aucune utilité et on peut les effacer à la fin de l'exécution des simulations.
http://aix1.si.usherb.ca/sp_soft/easy_ref.htm
Points à surveiller lors de la soumission de calculs
* Le temps de calculs à supplier lors de la soumission sert de borne limite de temps alloué. Il doit donc être choisi de façon à ce que vous ne soyez pas pénalisé par cette contrainte. Bien sur, il est possible de donner un temps de calcul exagéré lors de la soumission, notamment en cas de doute sur la durée de simulation. Cependant, dans certains cas une estimation plus précise du temps de calcul sera nécessaire principalement à cause des horaires de temps de calcul du SP2. Pour l'instant, l'horaire du SP2 est le suivant:
Période Limite Jour 24 noeuds-heure, max. 4 heures Nuit (sur semaine) 240 noeuds-heure, max 15 hrs Fin de semaine 1024 noeuds-heure, max 63 hrs du vendredi 18h à lundi 9h
* Le temps de calcul d'un programme parallèle est supérieur au temps de calcul de son équivalent séquentiel même dans le cas d'un programme parallélisé intégralement à partir d'un programme séquentiel (ce qui est le cas pour l'algorithme parallèle MCQ). Il s'ajoute dans l'utilisation du SP2 un temps supplémentaire nécessaire au passage du programme à chacun des processeurs, un temps de réponse du gestionnaire de travaux, etc. Quoique ces opérations ne prennent pas beaucoup de temps, un temps supplémentaire de 1 à 4 minutes est à prévoir en plus du temps de calcul normal.
* En mode individuel, le temps de calcul demandé doit être supérieur ou égal au temps de calcul de la plus longue simulation. (section 2.3.2)
dseed.# trnp.datLa première ligne contient le nom du fichier où le processeur ira chercher la valeur du germe alors que la deuxième contient le nom du fichier contenant les paramètres physiques. Par exemple, le noeud 0 ira lire en entrée primaire
/home/htouchet/tampin.0le nom du fichier
dseed.0par la commande du programme
READ(*,*) NOM_FICHIER_DU_GERMEet le nom du fichier des paramètres de simulation par la commande
READ(*,*) NOM_FICHIER_PARAMÈTRES_PHYSIQUESLe processeur procède alors à l'ouverture de ces fichiers par les commandes du programme:
OPEN(2,FILE=NOM_DU_FICHIER_DU_GERME) OPEN(3,FILE=NOM_DU_FICHIER_PARAMÈTRES_PHYSIQUES)pour ensuite faire référence à ces unités dans les lectures subséquentes. On voit donc bien la différence entre l'entrée primaire et les entrées secondaires. Dans le cas des unités d'entrée primaires, il n'est pas nécessaire d'effectuer des commandes CLOSE. Ce sont des unités implicitent. L'utilité de ce mode est d'obtenir des résultats Monte Carlo statistiquement plus fiables puisque dans ce mode, l'exploration de l'espace des phases du système considéré se fait par plusieurs processeurs indépendants. C'est le programme de statistiques, lancé automatiquement après l'exécution des simulations, qui procède au moyennage des résultats des noeuds. Ce programme est décrit dans la section 3. Il est à remarquer que le mode processeurs communs utilise la version
monteh3.scriptdu script de parallélisation. Cette version du script ne diffère des autres que par l'ajout de la commande démarrant le programme de statistique.
Une attention spéciale doit être portée au seul point distiguant les diverses simulations du mode commun: le générateur de nombre pseudo-aléatoires et plus spécifiquement, le germe de chacun des processeurs. Comment doit être choisi ce germe? Comment s'assurer que les séquences de nombres aléatoires de chacun des noeuds sont disjointes? C'est seulement en répondant à ces questions qu'il est possible de déterminer la qualité statistique des résultats du mode commun, de s'assurer d'une plus grande exploration de l'espace des phases et donc d'une ergodicité accrue de l'algorithme. L'étude de ces questions est présentement en cours.
dseed.# trn.#On voit dès lors que dans ce mode, le répertoire doit contenir autant de fichiers trn.# (contenant les paramètres physiques) que de noeuds commandés en plus de contenir autant de fichiers de germes (comme dans le mode précédent d'ailleurs). Dans ce mode, aucun programme de statistiques n'est activé. Les résultats sont contenus dans les fichiers
diary.#L'utilité principale du mode individuel réside dans le fait qu'il est possible de faire l'étude rapide de l'effet d'un paramètre de simulation. Par exemple, une étude en température se fait en assignant un b différent à chaque noeud. Le gain en temps de calcul est alors phénoménal puisque le temps requis nous permettant d'effectuer seize simulations correspond au temps de calcul de la plus longue simulation (généralement celle ayant le b le plus élevé). Comme aucune valeur statistique n'est calculée à partir des valeurs obtenues dans ce mode, il n'est pas obligatoire d'assigner un germe différent à chaque noeud.
diary.#pour en stocker les valeurs dans des objets ayant tous une dimension caractéristique (0:16,...) pour l'emplacement des valeurs en fonction de la provenance (# du noeud) des résultats. La première dimension est fixée à 16 parce que 16 noeuds sont disponibles sur l'ordinateur parallèle. La nomenclature des noms des objets est clairement expliqués dans le programme.
Le déroulement du programme est le suivant:
1- Le programme lit les données des différents noeuds.
2- Il procède au calcul des différentes moyennes en plus de d'autres valeurs statistiques comme l'écart-
type et l'écart-type pondéré.
3- Il écrit ensuite les résultats de ces calculs dans le fichier results.dat,
les résultats étant tous bien identifiés sous une forme complète.
Ce programme, entièrement séquentiel, a fait l'objet de tests qui ont démontré que tous les calculs se faisaient correctement. Deux remarques peuvent être faites au sujet de la construction de ce programme. Premièrement, La sous-routine
NUMTOASCIIqui fournit les noms des fichiers par défaut (préfixe et suffixe numéral) travail implicitement avec un préfixe donné dans la sous-routine
LECTURE_DATASi on change de répertoire de travail, ce préfixe doit être lui aussi modifié ainsi que le nom du répertoire du fichier des résultats qui est ouvert dans le programme principal. Ces mêmes changements doivent bien sûr être faits dans le fichier soum. Deuxièmement, le programme stat3.f qui sert à calculer les différentes quantités statistiques (moyennes, écart-type, écart-type pondéré) à la fin des simulations en mode commun a une structure très rigide. Il a été construit exclusivement en fonction du nombre de sorties du programme de simulation dans ce mode (progch3.f). Ainsi, advenant un changement au niveau du nombre ou de l'ordre des sorties, il sera nécessaire d'effectuer des changements au niveau des entrées et sorties (ordre et nombre) du programme de statistiques sans quoi ce programme ne calculera pas les bonnes valeurs.
Références sur le Web
Plusieurs renseignements sur le SP2 sont disponibles sur le site Web du Centre d'applications en calcul parallèle de l'Université de Sherbrooke (CACPUS) à l'adresse suivante:
http://aix1.si.usherb.ca/cacpus.htmet des informations précieuses concernant la parallélisation sont disponibles aux sites suivants dont l'auteur est Christian Foisy, spécialiste en calcul parallèle au CACPUS: Manuel des usagers du SP2:
http://aix1.si.usherb.ca:80/SP_GUIDE/docf/Notes du second séminaire:
http://aix1.si.usherb.ca/SP_GUIDE/semin2f/semin2f.htm
Remerciements
J'aimerais remercier André-Marie Tremblay et Samuel Moukouri pour leur aide précieuse ainsi que Christian Foisy pour avoir répondu à toutes mes questions en plus de m'avoir fourni quelques lignes inestimables de Fortran.
#!/bin/csh # # Author: Christian Foisy, CACPUS # Date: October 1995 # # File: monte.script # # Purpose: run multiple copies of a sequential program on the SP2 with EASY # # Usage: # # - submit this script as usual with spsubmit # - the arguments that must be given are: # # myprog mydir input output # # where # myprog: is the name of your program # mydir: is the directory which contain input/output files # (and your program if you did not specify a full # pathname for myprog) # input: prefix for the input files # output: prefix for the output files # # Example: # # You are joe_user, your program foo and input files bar.* are in # /home/joe_user/sp2/ # # arguments for spsubmit: foo /home/joe_user/sp2 bar result # # The first node will read standard input from bar.0, the second node will # read standard input from bar.1, and so on. The same thing for the # standard output: result.0, result.1 and so on. If your program # doesn't need some redirection, removes it from the poe line # above (BUT LET THE "&" AT THE END OF THE LINE). # # WARNING: if your program write output files (besides the standard output), # ***be sure that they write to different files***. A good programming # practice is to give output filenames as input. You will get uncecyperable # results if you do not follow this advice. # # WARNING 2: don't forget to do "chmod u+x" on this script file. # # POE/EASY environment # setenv JID `/prog/SP_Scheduler/getjid` setenv MP_EUILIB us setenv TMP_HOSTFILE $HOME/SPnodes.$JID setenv HOSTFILE $HOME/.SPnodes. setenv MP_PROCS 1 setenv MP_INFOLEVEL 0 setenv LANG En_US # # script variables # setenv PROG $1 setenv WORKINGDIR $2 setenv INPUTFILE $3 setenv OUTPUTFILE $4 # # Change this directory to the one containing your program # A la fin du programme de simulation, le programme stat2.out # est lance (Hugo Touchette 1996) # cd $WORKINGDIR # @ num = 0 foreach host (`cat $TMP_HOSTFILE`) setenv MP_HOSTFILE $HOSTFILE.$num echo $host >! $MP_HOSTFILE echo "On node: "`cat $MP_HOSTFILE` echo "Input/output: "$num poe $PROG < $INPUTFILE.$num >! $OUTPUTFILE.$num & @ num = $num + 1 end wait /home/htouchet/montec/stat3.out echo "Done\!" sleep 30 #