Bonjours,

Je vais vous expliquer le contexte avant d'entrer dans les détails pour enfin poser mes questions. Si vous vous en fiché du contexte (parce que j'écrit trop XD), passez directement à la question tout en bas avant les P.S. . Le langage utilisé est décrit dans le P.S .

Un ami a fait un programme de post process d'un code de calcul quantique, plus précisément de l'AIMD (pour Ab-Initio Molecular Dynamic). Ce programme n'a, en fait rien avoir avec la mécanique quantique, il ne se sert que des positions, vitesses, forces ... etc des atomes du système qui ont été déterminés par le code de calcul quantique.

Son petit programme est génial et extrêmement pratique, seulement, il ne s'en occupe plus (étant donné qu'il a autre chose à faire, et qu'il a déjà fait un excellent boulot). L'une des fonctionnalité de ce programme est de calculer la fonction de distribution radial, ou g(r) ou encore RDF en anglais. Et il se trouve qu'il est en parti erroné. Je me suis donc mis à le corriger, et de file en auguille j'y ajoute quelques fonctionnalités supplémentaire, comme l'intégrale du g(r), le g(théta) (ou fonction de distribution angulaire) ou encore la probabilité de présence des voisins ...

Je sens que vous êtes perdue. Je vais vous expliquer ce que tout cela signifie. Le g(r) est une fonction qui représente le nombre d'atome moyen présent autour d'un atome à un rayon r. Il a cette tête : http://en.wikipedia.org/wiki/Radial_distribution_function (bon, d'accord, c'est wikipédia, mais pour ce que j'ai à vous montrer, ça suffit amplement. Le g(r), c'est la fonction oscillante en dessous de l'image avec les atomes, à droite). Son intégrale correspond au nombre d'atome moyen présent autour d'un atome dans une sphère de rayon r.

Le g(théta), c'est la même chose mais avec les angles. Et la probabilité de présence des voisins, c'est une fonction dont je ne connais pas le nom réel, mais qui permet de donner la probabilité selon laquelle le nième voisin d'un atome va rester son nième voisin après x itérations, indiquant, dans un liquide notamment, une structure atomique au sein de ce liquide (là où j'ai vu cette astuce, c'était pour du lithium. A 100 K et 180 GPa environ, le lithium est liquide, et les atomes ont tendance à se regrouper en tétraèdres).

Bref, j'ai programmé tout ça. ça a l'air de plutôt bien fonctionner, mais voilà, le g(théta) fonctionne pour de "petits" systèmes.

En gros, dans la fonction, je lui donne le nombre de voisin à prendre en compte (car on peut lui dire de calculer les angles formés entre les 3 atomes les plus proches, ou les angles de tous le système, même s'ils sont distants), ainsi que le nombre d'itération de dynamique moléculaire à prendre en compte (pour moyenner la répartition sur l'ensemble de la dynamique, et non pas sur un unique pas de temps), et d'autres paramètres qui ne posent à priori pas de problème.

Un exemple qui marche est quand je prend 1835 pas de dynamique et jusque 8 voisins, ça fonctionne. Au 9ième voisins, ça plante (le calcul s'arrête, et l'interface disparait ... en gros, le programme se ferme). Pour vérifier si c'est sur les voisins que ça pose problème, j'ai pris 10 pas de dynamique avec 107 voisins, ça fonctionne. WTF ?

J'ai déjà eu ce genre de problème (programme qui se ferme sans message d'erreur), et il s'agissait d'un problème de dépassement de matrice. Ici, je stock beaucoup de données (les calculs sont très rapide cependant), et je me demande, sachant que j'ai cherché un dépassement de matrice sans en avoir trouvé, est-ce qu'il ne s'agirait pas d'un problème de cache ? Genre, pendant le calcul, le cache stock temporairement les données, et comme il y a beaucoup d'itérations effectuées, il fini par ne plus avoir de place et plante.

De temps en temps, il me marque une erreur avec marqué "Memory map: ..." et tout un tas de babla numérique sur la mémoire, avec, en fin, "Abandon python2.6 appa.py"

Donc, une question pratique, à laquelle vous êtes en mesure de répondre (car sans le code, vous ne pourrez pas attesté que je ne me suis pas planté quelque part XD ce qui est possible, j'ai peut être mal vu. Je vous présenterez plus en détail le programme si ce que je pense ne résous pas mon problème) :

Quel est la ligne de commande qui permet de vider le cache mémoire utilisé lors d'un calcul ?

P.S.: je n'ai pas précisé, mais le programme globale est un programme python, et mon problème se situe dans une subroutine fortran (d'où le terme f2py qui est fortran to python). Cela a été fait ainsi car fortran a une vitesse de calcul démentiel en comparaison de python, mais à l'inverse python est extrêmement pratique pour gérer les interfaces. Grâce à cette expérience, j'ai aussi appris à manipuler la programmation orienté objet, et c'est franchement génial ... en tout cas, pour les interfaces et l'utilisation de subroutine ^^.

P.P.S.: si ça vous parait impossible (genre, lorsqu'il n'y a plus de cache, il réécrit par dessus, ou encore, il faut vraiment beaucoup d'itérations pour remplir le cache ... etc) n'hésitez pas, ça peut toujours m'être utile d'avoir des détails de fonctionnement supplémentaire sur ce type de sujet. Et encore une fois, c'est peut être moi qui n'ai pas vu mon erreur. Simplement, en faisant des print, j'ai repéré qu'il avait l'air de s'arrêter en plein milieu d'une boucle sans raison visible (et justement, sans dépassement de taille de matrice).

Je ne sais pas ce que ca veut dire "vider le cache memoire utilise lors d'un calcul". Si tu parles du cache du processeur, il n'y a rien faire, il se vide tout seul. Si ton applicatino cache de facon logicielle certain resultat (ce qui est classique dans ce genre de code scientifique) alors le caching est dependant de l'application.

De ce que tu racontes le probleme que tu rencontre est simplement une faute de segmentation. Si le code qui genere l'erreur est le code fortran, alors tu peux certainement obtenir plus d'information avec un outil comme valgrind. De facon general attache un debugger a ton application et regarde le contexte au moment de l'erreur.

Aussi, note que les gens qui ecrivent du fortran ont une facheuse habitude de faire des suppostion sur les cas qu'ils vont faire tourner et d'allouer des tableau statique qui sont juste suffisament grand pour leur probleme. Si tu essaey d'augmenter la taille de tes calcul et que ca commence a faire n'importe quoi, il est possible que tu rencontres la meme situation.

Merci pour ces informations.

Ce que j'entend par "vider le cache", c'est que je pense probable le fait que l'erreur de segmentation ne vienne pas directement de mon programme, mais de la mémoire allouée lors du calcul.

Cela dit, tes explications montrent que ce n'est pas possible (du moins, c'est ce que je comprend) et donc qu'il y a un dépassement de taille de matrice quelque part que je n'ai pas encore trouvé. L'ennuie est que je ne vois absolument pas où ça pourrait se situer étant donné que le calcul semble s'arrêter en plein milieu d'une boucle, dont les incréments ne peuvent dépasser la taille des matrices.

Et effectivement, j'alloue bien une taille fixe à mes matrices. Simplement elles sont fixes pendant la durée d'un calcul, et varient en fonction du cas de calcul que j'effectue. Mais ça m'est déjà arrivé de faire un programme en fortran et de donner une taille fixe. C'est d'ailleurs à cause de ça (ou grâce à ça, dépend du point de vue) que je sais que ce type d'erreur est due à un dépassement de mémoire allouée. Le problème en fortran est qu'on est obligé de déclarer les variables au début du programme, et qu'on ne peut utiliser de variable non défini dans les tenseurs (ou en tout cas, la solution n'est pas trivial). Ici, c'est une subroutine, donc les variables d'entrées peuvent correspondre aux tailles de matrices désiré. Donc cela est beaucoup plus facile de faire s'adapter le calcul à la situation donnée.

Quoiqu'il en soit, je te remercie encore pour ta réponse, je vois que l'erreur vient forcément de moi (ça me rassure quant aux capacité de mémoire des calculs ... en même temps, ça parait logique, mais bon, il faut bien explorer chaque piste avant de les éliminer). Je vais voir pour ajouter un debugger et trouver le problème. J'ai certainement due oublier un détail important.

Je vous tiendrez informé.

regarde la quantite de memoire alloue sur ta machine, tu peux atteindre Out-of-memory qui en fonction de la politique d'allocation du systeme peut ne pas etre detecter lors de l'allocation mais lors de l'utilisation.

Bonjour,

Moi quand j'ai ce genre de chose, je me fait une version de debug, avec toute les lignes ou presque en commentaire dans un fichier log.

Par exemple "Essais d'allouer 999999mo", "Allocation réussi" (ou raté .

Merci à vous. J'ai utilisé le débugger gbd et ai trouvé que c'était bien moi qui avait un soucis.

En fait, je calcul les angles entre les atomes en calculant le produit scalaire entre deux vecteurs. Par exemple, 3 atomes ABC, je cherche l'angle BAC, alors je calcul le produit scalaire avec les vecteurs AB et AC. D'une part avec la définition vectoriel du produit scalaire (x1.x2+y1y2+z1.z2) puis en utilisant la formule qu'on voit à l'école dAB.dAC.cos(BAC). J'inverse donc la formule pour obtenir BAC.

Et là, patatra, j'avais pas fait gaffe, mais je me retrouve parfois à calculer l'arccos d'un nombre inférieur à -1. Que fait-je alors ? Et bien j'ai mis une condition pour dire qu'en fait c'est 180° (car j'obtient pas -2 ou -3 ... c'est juste -1.008 par exemple).

Et j'avais un autre problème, c'est quand l'angle valais 0°, je l'introduisais dans un vecteur en lui demandant de le mettre à l'emplacement 0 (typiquement, un vecteur nommé HIST et qui a 180 lignes). Ces cas là, je les ai supprimés avec une autre condition.

A la limite, je ne devrais pas les supprimer, mais ajouter une ligne supplémentaire pour la prendre en compte (tien, je n'y avais pas pensé jusque là).

Bref, encore merci. Et comme d'hab, c'est jamais la faute d'un logiciel de programmation (ou en de très rares occasion et encore, à ce moment là, c'est la faute du programmeur de ce logiciel, ou c'est l'utilisateur qui chipote sur des virgules flottante que le processeur ne peut pas maîtriser) et toujours (ou quasiment) de la faute de l'utilisateur. Comme quoi, ça se confirme, l'erreur est humaine

Les problemes de compilateur ou de hardware existent, mais souvent l'erreur vient du programmeur final. Ou des fois d'une lib un peu trop experimentale.