Discussion :

[deadhand]

Salut tout le monde ! Voilà un problème qui me court après depuis déjà une semaine.

J'avais une liste de bloc common que j'ai convertit en module. Il n'y a pas d'erreur de conversion ou de déclaration. j'ai tout vérifier pas à pas.

Lorsque je fais tourner le programme, les résultats des calculs effectués changent de la version initiale mais si j'écris la valeur de chaque variable du module (j'ais fait ca pour voir la quelle pouvait être mal déclarée) dans un fichier qui n'est utiliser a aucun moment par le programme, les résultats redeviennent corrects. Si je commente les lignes qui enregistrent les variables dans les fichiers, alors les résultats redeviennent mauvais.

Si quelqu'un à une explication à cette situation, je suis preneur !!

Aidez-moi !

[Marlan]

Salut,

Ayant déjà eus le même soucis, je pense que le tiens doit être similaire: as tu bien utilisé le IMPLICIT NONE dans chacun de tes modules? Si oui, alors je pense que ceci doit être un problème d'initialisation de variable au sein des modules.

En effet, il se peut que tu ais pu oublié de définir une variable que le programme va alors chercher dans ce qui a déjà été fait ou dans ce qui reste en mémoire de ton ordinateur. (expemple: calcul d'une variable X au sein du programme principal et mauvais export/import de la variable dans l'un des modules)

[genteur slayer]

si lorsque tu fait l'affichage (par un print ou un write) des variable cela marche et cela ne marche pas si tu ne le fait pas, c'est bien souvent un problème mémoire:
les print et write vont lors de leur éxecution vidé le buffer mémoire et donc effacer les éventuels erreurs de lecture des variable...

comme l'a dit Marlan, vérifie les implicit none et les variable éventuellement déclarée implicite... il se peut que ton prog aille lire une variable toto(8) alors que le tableau toto n'a que 7 éléments...

en mémoire, il se peut aussi que toto(8) pointe vers la valeur suivante en mémoire et que du coup tu n'accede pas à la valeur que tu aurait souhaité:
... toto(6) toto(7) titi
...|-------|-------|-------|-------|-------|....
en gros toto(8) te renverra la vamleur de titi

quel est ton compilo? sous gfortran (et autres dérivé de gcc) tu peut utiliser l'option de compilation/link "-fbound-check" qui vérifira (un peu) les dépassement de tableau
cela peut aider à trouver le problème

[deadhand]

Merci à tout les deux.

Je vérifie tout de suite.

[deadhand]

Re salut !

Alors, dernier développement de l'affaire. J'ai identifié 5 variables dans 4 modules qui faisaient changer les résultat et parmis ces varaibles seulement 3 sont des tableaux. Les deux autres sont un int et un real, alors comment la suppression du buffer pour un réel ou un entier peut en changer la valeur ??????????

Help !!!

[Ehouarn]

Bonjour,

En plus des cas déjà évoqués, il y a aussi les possibilités de variables réutilisées par une routine lors d'appels successifs alors qu'elles n'ont pas l'attribut "save" et/ou une mauvaise correspondance entre les arguments donnés à l'appel d'une routine (ou fonction) et ceux attendus par celle-ci.

Bonne chasse...

[genteur slayer]

de plus il est possible de changer de nom dans les bloc common entre deux subroutine exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
subroutine toto1
 
common / toto / titi(8),ititi(7),ivar,rvar
....

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
subroutine toto2
 
common / toto / titi(5),ititi(10),rvar2,ivar2
....

ainsi dans toto2 on change même le type de variable en passqant du Real*4 au integer*4 .... donc dans ces cas là, tu as des possible pertes de précision, des variables inconnues etc... lorsque tu utilise un module les variable ne peuvent changer de nom entre deux routines...

tu peux vérifier que dans tes ancien common les gens avaient bien donner le même nom de variable à chaque fois! sinon: maintenant qu'elle ont toute le même nom dans toutes les routine, il y a peut-être une routine qui ne modifie plus la variable alors qu'elle devrait

[deadhand]

Salut !

Encore merci pour vos réponses.

Mais hélas ... le problème subsiste toujours. J'ai ajouté l'attribut "save" à mes modules et le résultat reste le même.

Les bloc common étant déclarés dans des fichiers qui sont inclus après dans le code, ils sont toujours déclarés de la même façon.

L'erreur ne reste pas constante mais augmente au fil des calculs pour donner un résultat aberrant à la fin.

Help moi !!!! Ca fait plus de trois semaines que je suis sur ce fichu problème !!!!!

[genteur slayer]

as-tu accès à tes deux codes source? si c'est le cas: youpi!!

l'idée: faire du profiling pour voir les différence de fuites mémoire
donc à l'aide de programmes comme valgrind, gprof
mais ils vont faire bcp de choses dont tu n'a pas besoin...

autre méthode, plus longue...
comme tu connais les variables impactées: tu fais une recherche de ces variables dans tout tes fichiers et à chaque accès tu écrit dans un fichier de log leur valeur, et l'endroit où elle sont accedé (en écrivant une petite fonction 'log_var' par exemple) et tu fait tourner les deux codes: tu as deux fichiers de log....
ensuite un diff entre ces deux fichiers te donne exactement l'évolution de ces variables. et les bifurcations.

une fois identifié l'endroit exact on peut mieux savoir ce qui ne va pas.

dans la fonction de log, il est important d'écrire l'ancienne valeur et la valeur modifié: d'une ligne à l'autre il dois y avoir correspondance, sinon-> écrasement mémoire!!!

[deadhand]

Merci encore de ton aide.

Le log, j'y avais pensé mais j'espéré ne pas avoir à le faire ... Surtout qu'il y a une évolution. J'ai mis en commentaire toutes les écritures des variables (que j'avais fait pour le log) et j'ai rajouter un 'save' pour toute les variables des modules. Du coup, le calcul final ne change presque plus et apparement, il s'agit d'un souci de précision : un real qui passe de 21.95502 à 21.95509 par exemple. Les variations deviennent plus conséquentes au fur et à mesure de l'évolution d'un autre résultat car il se sert des valeurs actuels et précédentes des variables (dont la précision semblent changer) pour ses calculs.

Donc nouvelle intérogation, qu'est-ce qui peut provoquer ce changement de précision depuis le passage des common blocks au module ?

Bien sur, il ne s'agit peut-être pas d'un problème de précision mais peut-être d'une légère variation du problème précédent ...

Si tu as une idée, j'avoue que depuis trois semaines que je suis dessus, je commence à suffoquer ...

[genteur slayer]

bon, j'imagine que tu as déjà vérifier que tu ne faisais pas de conversions simple précision vers ou depuis des doubles precision
et j'imagine aussi que tu as déjà essayer le changement de compilo (pour les deux versions) et d'OS...
(vérifications de base devant ce genre de problèmes)

ensuite le save n'est pas nécessaire normalement....

sinon autre méthode... tu commente absolument tous les accès en écriture à ta valeur (sauf la première histoire que ça soit non nul si par hasard tu divisais...) et tu compare les résultats des deux codes uniquement sur cette valeur... si tu démarre déjà avec des différence ->écrasement mémoire
sinon, bin petit à petit tu dé-commente jusqu'à trouver une différence....

il faut d'une manière ou d'une autre que tu détermine où il y a un soucis!! c'est long et chiant.... mais il faut!!!

[Arixo]

Salut,

j'ai déjà eu un problème comme ça : les résultats étaient faux, mais en ajoutant "print*, 'toto'" dans une routine tout redevenait juste ! On a aussi vu que sans le print mais en empêchant l'optimisation avec -O0 sur la routine ça marchait.

Il s'agissait d'un problème de variable pas initialisée et l'explication était la suivante :

sans le print, le compilo optimisait la routine et n'initialisait pas automatiquement la variable à 0 (valeur qu'elle devait avoir en effet) et avec le print il optimisait la routine et n'initialisait pas la variable, du coup ensuite le code utilisait n'importe quoi comme valeur, et ça tournait sans tout faire planter mais les résultats étaient faux.

On a vu ça en passant de pgf90 qui initialisait toujours tout à 0 par défaut (le vilain) à ifort qui ne le faisait pas.

Pour trouver ce genre de choses, les compilateurs peuvent proposer des options de "test à l'éxecution" (souvent -C, ou -check, ça dépend du compilo), et si ça ne suffit pas, valgrind est fait pour ce genre de choses comme dit ci-dessus.

bon courage,