Discussion :

[dva2tlse]

Bonjour les gens du forum,
à mon boulot, j'ai à faire un assez gros programme en fortran, gros pour moi qui ne suis pas informaticien mais ingénieur mécanicien, et ce programme doit tourner assez vite pour être utile. Une certaine tâche de base (très complexe cependant) met quelques secondes à touner, et il faudrait en faire environ trois cent mille dans la semaine, ce qui laisse environ deux secondes par tâche unitaire.
J'en ai déjà parlé plusieurs fois sur ce forum, et l'on m'a bien aidé; ce qui se passe désormais, est que j'ai décidé de paralléliser l'affaire avec openmp, puisqu'il y a dans ma boite plusieurs machines multiprocesseur, et qu'il me semble être arrivé à peu près "au bout" des optimisations sur un seul proc'; je vois donc ainsi, en parallélisant, une issue possible satisfaisante.
Cependant, pour l'instant je bute sur une particularité du calcul parallèle : après avoir commencé séquentiellement, le calcul devient parallèle, et il faut choisir soigneusement parmi les données, celles qui vont être propres à chaque branche du calcul (PRIVATE), et celles qui vont être partagées entre toutes les branches. (SHARED)
Et c'est à ce moment là que mon programme plante, et je n'arrive pas à en connaître la raison.
J'ai essayé de compiler (j'utilise gfortran) avec l'option "-g" pour pouvoir utiliser le debugger gdb, et voici ce qu'il me raconte après un démarrage ordinaire :

Cannot access memory at address 0x7ffffd8a2618
0x0000000000407c61 in MAIN__.omp_fn.0 (.omp_data_i=) at /L/DATA_PROJECTS9/DAVID/F90/BN/rfomp1.f:1183
warning: Source file is more recent than executable. [ce qui n'est pas vrai, mais il le dit toujours]
1183 C$OMP+SHARED(Ccvt1, Ccvt2, elem, elemout, FSCVT2, lina)
Cannot access memory at address 0x7ffffd8a2618

Je ne connais pas gdb (sauf "bt"), alors j'ai essayé de demander "info symbol 0x7ffffd8a2618", en espérant avoir le nom de la variable boiteuse, mais il répond "No symbol matches 0x7ffffd8a2618.".
Dans gdb, "info variables" me donne une longue liste d'adresses avec les variables correspondantes, mais pas la bonne adresse, et donc je ne sais pas quelle variable pose problème, ce qui pourrait pourtant m'aider grandement.
Les divers tutos et user guides que j'ai pu consulter, m'indiquent comment faire du pas à pas, mettre des points d'arrêt et lire les valeurs des variables, mais pas ce que je veux.

Comment puis-je savoir quel est le nom de la variable qu'il n'arrive pas à atteindre ?

Merci de m'aider autant que possible,
David

[dva2tlse]

Ça y est youpi ça marche; le souci que j'avais jeudi et avant sur le multi-threading est résolu; jeudi j'avais demandé de l'aide à deux américains qui bossent sur un forum d'aide aux personnes qui utilisent comme moi l'API (Application Program Interface) openMP pour les tâches en Multi Processeur, et ces gens là m'ont demandé de leur poster mon programme principal qui déconnait, ainsi que les déclarations de variables qui sont faites dans tous les sous programmes pour examiner le tout.
Et vendredi matin j'ai voulu de mon côté continuer d'examiner le problème, donc je suis allé sur leur site et j'ai recopié ce que j'avais posté la veille jeudi, pour le faire tourner chez moi sur ma machine; je n'avais que des subroutines complètement bidon, qui ne faisaient aucun travail avec juste un RETURN après les déclarations, mais comme c'est justement les correspondances entre les déclarations et les arguments des subroutines et ceux utilisés lors des appels que je mettais en cause, eh bien ça m'a permis de m'apercevoir que dans le sous-programme valint qui nettoie une colonne de l'historique de ses valeurs intermédiaires, eh bien ce sous-programme s'attendait à recevoir un argument valinter déclaré comme valinter(31640, 326), soit une matrice, alors que le programme principal rfomp1 ne lui passait qu'un valinter déclaré comme valinter(31640), soit une colonne, ce qui est logique, mais ça ne correspondait pas.
Je ne sais pas depuis quand je traine cette erreur, mais il est possible que ce soit depuis cet été, juste avant ou juste après les congés; enfin bref, lundi ça devrait marcher pour ça, et il ne restera "plus" qu'à s'occuper proprement de deux moyennes choses héhop.
David