Discussion :

[bobbyboy]

Bonjour,

Je développe un programme qui doit tourner sur un PC personnel (proc : intel i7 4 coeurs 64bits, 4 Go RAM), et je compile avec gfortran. Ca tourne sous Windows 7.

Je suis obligé déclarer des tableaux assez gros de REAL*8 (10^5 x 10^5) . Je compile sans pb mais l'exécution plante au moment de l'allocation. Sur l'OS j'ai un indicateur de RAM utilisé et ca plante au moment où c'est plein. Par contre si je diminue la taille de mes tableaux, là tout roule.

Soucis 1 :
--------
Est-il possible de faire en sorte que le programme utilise la mémoire du disque dur pour certaines variables trop grosses ? Option du compilateur ou déclaration particulière en FORTRAN ?

Soucis 2 (plus par curiosité) :
--------
Peut-on faire tourner le code en parallèle avec MPI sur les 4 coeurs ?

Toute solution est bienvenue
Merci

[FR119492]

Salut!

Je suis obligé déclarer des tableaux assez gros de REAL*8 (10^5 x 10^5)

Es-tu absolument certain d'être obligé? N'y a-t-il pas des astuces pour l'éviter?
Jean-Marc Blanc

[bobbyboy]

Bonjour,
non je n'ai pas la choix, c'est un code de méca flu. L'allocation de mes tableaux se fait en fonction des maillages que je traite. Je suis obligé de d'avoir accès à l'information de chaque maille.
Typiquement mon maillage fait 10^4 * 10^4, et je dois pouvoir stocker au moins 6 variables sur chaque maille.

Donc pour l'instant je suis limité sur la taille de mes maillages.

[bobbyboy]

Je viens de penser à un truc :
Je sais que les OS linux permettent de définir une partition SWAP qui prend le relai de la RAM si besoin.
Donc en passant sous Linux, je peux peut-être régler mon pb ? Quelqu'un peut-il me confirmer ?

[genteur slayer]

sous windows, le swap est un fichier à la racine de C: nommé pagefile.sys (ou mémoire paginée) tu peut régler sa taille dans propriété du poste de travail. cela dit dans ce cas, cela ne sert à rien.
de plus si ton maillage fait 10000x10000 pour 6 ddl... tu peut te restrindre à un tableau de 600 000 000... ensuite ta matrice de rigidité devrait être de 600 000 000 x 600 000 000 mais on ne se sert JAMAIS de toutes ses composantes, de plus si tu fait de la méca flux, je suppose que tu utilise navier-stockes donc une équation non linéaire (à cause du div(u*u)) donc ta matrice de rigidité change tout le temps -> utilise des méthodes sans matrice! au moins tu règle le problème de mémoire et augmente peu le nombre de calcul dans ce cas d'application!

p.s. attention, si ton compilo gfortran bosse sous cygwin, cygwin n'existe que en 32bits donc gfortran également, il ne sera pas capable d'alouer plus de 4Go (à une vache près) de mémoire en comptant tout (place du programme, de la pile et du tas)


ah et...: MPI : BIENSUR!!!!!!! voir sur ton core i7 avec l'hyperthreading windows voit 8 coeurs, utilise les!!!! (note cela ne change pas l'utilisation mémoire)

[bobbyboy]

ta matrice de rigidité

Petite précision : Je n'ai pas de matrice de rigidité (c'est de la méca flu).

mais on ne se sert JAMAIS de toutes ses composantes

Ben si !
Pour faire avancer le vecteur d'état (5 composantes/maille au moins) d'une maille, je résouts effectivement les eq de conservations de Navier-Stockes. La résolution dépend des vecteurs d'états des mailles voisines. Donc pour faire avancer mon système complet d'un pas de temps, j'ai besoin de l'information de toutes les mailles.
Donc au minimum, je dois allouer un tableau d'état de mon système de taille :
ETAT (nb_mailles,nb_composantes)

C'est sans compter les tableaux intermédiaires qui permettent de faire le calcul ( gradients, ...)

Tous les codes de méca flu eulérienne (ie : maillé) doivent stocker l'état de leur système à l'instant n, (voir même celui à n-1) selon l'ordre de résolution.
Donc peut importe comment tu les découpes, au final ca sera toujours au minimum :
nb_mailles*nb_composantes + nb de tableau intermédiaires