Problème de soumission d'un job en parallèle sur qsub

Version imprimable

12/11/2016, 16h56
plussoyeur

Problème de soumission d'un job en parallèle sur qsub
Bonjour,

Je ne sais pas vraiment où poster cette question. J'ai cherché mais n'ai pas vraiment trouvé de place adaptée donc désolé si ce fil de discussion n'est pas au bon endroit :?

Je vais vous exposer mon problème. J'ai un job en parallèle à soumettre à un centre de calcul (un code en fortran parallélisé avec du openMPI).
Or pour le lancer le code en fortran, je lance un script python qui étudie un fichier (de maillage) et écrit dans un autre fichier les résultats de qu'il lit (python.res). Puis ce script python lance le code fortran en parallèle à la toute fin du script :
Code:

1 2 3 4 5 import os .... os.system("mpirun -np {0} exe".format(nbSsDomains+1))
où nbSsDomains a été crée par python à la lecture du premier fichier (celui de maillage).
Jusqu'ici tout se passe bien.
Mais lorsque les jobs se lancent en parallèle ils disent tous qu'il manque le fichier "python.res". En fait ce qu'il se passe (en tout cas j'ai l'impression) c'est que la dernière ligne du code python est lancée avant que python ne crée le fichier python.res. Pire encore, d'après mes tests, j'ai l'impression que le processeur qui gère ce script Python attend que tous les autres proc aient fini leur travail avant d'écrire quoi que ce soit. En effet je fais un "print" dans le script python et il ne s'affiche qu'après la fin du code fortran.

Pour l'instant je suis donc obligé de m'assurer de bien crée le fichier python.res avant de lancer le job sur le serveur de calcul.
Des idées pour s'affranchir de ceci ou bien du pourquoi du comment ? :mrgreen:

Voilà, j'espère avoir été clair. Et merci de votre aide !
13/11/2016, 06h08
VinsS

Salut,

Si le fichier créé par Python est volumineux, il est parfois nécessaire de forcer l'écriture avec flush().

Toutefois, les disques durs utilisent, eux aussi, un tampon et on ne peut les forcer à aller plus vite, dans ce cas on fait une temporisation.

Cependant, tu dis que le fichier n'existe pas, or python crée le fichier dès l'ouverture en écriture donc c'est que ta commande mpirun est envoyée trop tôt.

Il semble que la structure de ton code soit en cause.
13/11/2016, 11h23
plussoyeur

Bonjour,

Merci pour ta réponse matinale VinsS. Le fichier crée par python n'est pas volumineux (une centaine d'octets tout au plus) donc ce n'est pas ça le problème.
Je peux te montrer mon code python si tu veux. Mais je fais la commande mpirun à la toute fin. C'est peut être une histoire (qui me dépasse) de gestion de processeurs car je demande 21 proc sur mon mpirun mais je me demande qui gère le script python pour justement réaliser cette commande mpirun.

Bonne journée !
13/11/2016, 16h45
VinsS

Ben oui, faudra montrer le code.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
# -*-coding:utf-8 -*
 
import os
import sys
import numpy
 
 
if len(sys.argv) > 1:
    filename = sys.argv[1]
 
else:
 
    filename = raw_input("Entrer le nom du fichier mesh \n")
 
    # Si jamais filename n'est pas specifie on lui donne testpart.msh
    # Valeur par defaut pour gagner du temps sur les tests
    if filename  == "":
        filename = "testpart.msh"
 
 
 
 
# Test de l'existence du fichier de maillage
try:
    with open(filename): pass
except IOError:
    print "*************************************************************"
    print "      ERREUR : le fichier spécifié n'existe pas              "
    print "*************************************************************"
    sys.exit(1)
 
 
 
file = open(filename, "r")
 
while 1:
    f = file.readline()
    if list(f) == ['$', 'E', 'l', 'e', 'm', 'e', 'n', 't', 's', '\n']:
        break
 
size = int(file.readline())
A = numpy.zeros(shape=(size,1))
 
for i in range(size):
    f = file.readline()
    f = numpy.fromstring(f, dtype=int, sep=' ')
    A[i] = f[6]
 
nbSsDomains = int(numpy.amax(A))
print "*************************************************************"
print "**                 INFOS PYTHON                              "
print "**  Le fichier lu est : ", filename
print "**  Le nombre de sous-domaines est :", nbSsDomains
print "**  Ce nombre est stocké dans le fichier : " "python_res.txt"
print "*************************************************************"
print
print
print
 
# Ecriture dans le fichier résultat lu par le code fortran
resultats = open("python_res.txt", "w")
resultats.write(filename)
resultats.write('\n')
resultats.write(str(nbSsDomains))
 
 
resultats.close()
 
file.close()
 
# Lancer le programme : mpirun -np nbSsDomains+1 exe
os.system("mpirun -np {0} exe".format(nbSsDomains+1))

Voici :)
Merci beaucoup.

13/11/2016, 17h49
VinsS

Comment ton code fortran a connaissance de l'emplacement du fichier "python_res.txt"

Avec ton code, le fichier est créé dans le dossier courant, celui où se trouve le script python.

Si tu confirmes que le fichier "python_res.txt" est bien créé alors le problème est peut-être son emplacement.
13/11/2016, 18h12
VinsS
Mouais, par curiosité j'ai fais une recherche sur mpirun et ceci en est le man:
https://www.open-mpi.org/doc/v1.8/man1/mpirun.1.php

Si c'est la commande expliquée dans le paragraphe Quick Summary que tu veux lancer
Code:

1 2 mpirun [ -np X ] [ --hostfile <filename> ] <program>
il est question d'un nom de fichier et d'un nom de programme.

Dans ton code le nom du programme semble être exe, est-ce vraiment son nom ?
13/11/2016, 19h09
wiztricks

Salut,

Mettez en commentaire la ligne 93 de votre programme: "os.system("mpirun -np {0} exe".format(nbSsDomains+1))" et lancez l'exécutable "à la console" directement.
Si çà ne fonctionne pas mieux, vous pouvez vérifier que le fichier a bien été créé (par Python), qu'il contient ce qui est attendu et que le soucis est dans le code fortran.

- W
13/11/2016, 22h12
plussoyeur
Alors pour répondre dans l'ordre :

@ VinsS :

En fait y'a une petite modification sur le code par rapport à celui envoyé :
Code:

1 2 3 4 5 resultats = open("/home/a11gr6/parallelisation/python_res.txt", "w") resultats.write(filename) resultats.write('\n') resultats.write(str(nbSsDomains))
Le code fortran à connaissance de l'emplacement car le script Python enregistre le fichier python_res.txt avec le chemin absolu et donc pour le code forrtan je reprends ce chemin absolu.

L'exécutable est bien l'exe. Le problème majeur ne vient pas du script Python. En fait je suis sur un centre de calcul et donc je me connecte sur la frontale. Si je lance le programme sur la frontale tout se passe bien. Si je lance le job avec qsub c'est là qu'il y a un problème. Le fichier "python.res" est bien crée mais j'ai l'impresison qu'il est crée après que les processeurs exécutant le code en fortran veulent le lire.
En effet je fais des write(*.*) un peu partout dans le code fortran. Et dans le fichier final crée, ces write du code fortran sont avant dans le fichier texte par rapport au "print" du code python (pour le job sur le centre de calcul, tout ce qui doit normalement s'afficher dans le terminal est stocké dans un fichier d'extension .o).

Pour être encore plus précis, le job marche très bien lorsque le fichier "python.res" est préexistant.

@wiztricks :

Je crois que mes remarques précédentes répondent à cette remarque. Le code fonctionne très bien :

1) Lorsque je le lance moi-même.
2) Lorsque je le lance via le script python sans le soumettre au centre de calcul par qsub.
3) Lorsque je le soumets au centre de calcul par qsub et que mon fichier "python.res" est préexistant.

EDIT : je viens de trouver mon erreur. Il venait du code fortran en fait. Le fait d'ajouter "/" dans le nom du fichier à lire (chose que je ne faisais pas pour la lecture en directe), trouble forrtan et un

Code:

1 2 read(n° du fichier,*)

ne suffit plus ,il faut plutôt écrire :

Code:

1 2 read(n° du fichier, '(a1024)')

(1024 par exemple) pour lui préciser de lire ça en temps que chaîne de caractère.

Et ce problème était cumulé à une erreur de chemin comme l'a fait remarqué VinsS

Merci beaucoup à tous les deux !