Discussion :

[julesu]

Bonjour,

Je travaille pour mon projet de fin d'études sur l'écriture d'un code éléments finis en Fortran.
Le code marche et est efficace pour de petits systèmes, mais dès que le nombre de nœuds augmente c'est la catastrophe au niveau gestion mémoire. J'ai fait pas mal de recherches mais je commence à m'y perdre entre mémoire virtuelle, pile, tas, etc. Bien que je comprenne à peu près les concepts en eux-mêmes, je ne sais plus sur quoi agir pour accélérer la vitesse d'exécution de mon code.

Prenons des matrices 10 000 x 10 000.
Problèmes :
- malgré une grosse RAM (16 Go) disponible, Windows XP(64) swape systématiquement sur disque sans utiliser toute la RAM. Comment l'éviter ?
- la machine possède plusieurs processeurs multicoeurs, mais seul l'un d'entre eux est utilisé. J'ai tenté une parallélisation en OpenMP, tous les coeurs sont sollicités mais la vitesse d'exécution ne s'en trouve pas améliorée, au contraire. J'envisage différentes explications: 1. je me suis planté quelque part en parallélisant, ce qui est fort possible ; ou 2. les piles de chaque thread contiennent des copies de mes variables, ce qui augmente le swap et donc ralentit l'exécution. Est-ce possible ? Avez-vous d'autres suggestions ?

A noter que j'ai augmenté la taille de la pile pour le programme (pas pour chaque thread car je n'ai pas trouvé comment faire).

En résumé, je ne sais plus comment gérer ces "grosses" matrices.. Quelqu'un aurait une idée ?

Merci d'avance !

[feynman]

pourquoi tomber dans ces problemes? y a un logiciel tres joli et important sorti de LJLL (Paris 6) c est Freefem++ qui est specifique pour la resolution par element finis . il te suffit d eccrir la formulation faible de ton probleme et quel type d elemnts finis tu veut et c est terminé!

[FR119492]

Salut!
Si j'ai bien compris ton problème, tu gaspilles ta mémoire RAM à stocker des termes nuls, et le temps de ton processeur à effectuer des calculs du type A+0 et A*0. Or, si on ne commet pas des maladresses majeures, la méthode des éléments finis conduit toujours à des matrices symétriques définies positives très creuses, c'est-à-dire soit de type "bande", soit tridiagonales par blocs. Dans le premier cas, je te recommande les sous-programmes DPBCO et DPBSL de la librairie LinPack disponible gratuitement sur www.netlib.org.
Jean-Marc Blanc

[julesu]

Merci de vos réponses !

Feynman, la réponse à ta question est simple: je tombe dans ces problèmes parce que c'est ce qu'on me demande en stage

Jean-Marc, les matrices sont en effet SDP. J'ai implémenté un algo de Cuthill-McKee afin de transformer la matrice en matrice bande. N'ayant pas trouvé une telle routine dans la libraire Math Kernel (Lapack) qu'on utilise, j'ai réécrit l'algo mais il est très probablement perfectible ! D'ailleurs ma routine est particulièrement lente, elle mettrait des heures à traiter une matrice 10 000x10 000..

Toutefois, Windows swape dès le lancement du programme, c'est-à-dire lors de la construction des matrices du système par calcul des contributions 2 à 2 entre les nœuds. Donc transformer en matrice bande ne résout pas le problème..

[FR119492]

Salut!

c'est-à-dire lors de la construction des matrices du système par calcul des contributions 2 à 2 entre les nœuds. Donc transformer en matrice bande ne résout pas le problème.

C'est évident! Tu dois construire directement ta matrice sous forme de bande, et non la compacter après coup.
Jean-Marc Blanc

[julesu]

Bonjour,

Ce que je n'ai pas précisé c'est que mon programme ne gère pas le maillage: il lit un fichier de maillage généré extérieurement, et donc les nœuds me sont fournis dans un ordre que je ne maîtrise pas.. d'où le compactage après coup en matrice bande.

[FR119492]

Mon pauvre!

Ce que je n'ai pas précisé c'est que mon programme ne gère pas le maillage: il lit un fichier de maillage généré extérieurement, et donc les nœuds me sont fournis dans un ordre que je ne maîtrise pas..

Je te plains sincèrement si on t'a imposé un mailleur boiteux.

Si ton mailleur te donne directement la matrice du système, je crains que ton cas ne soit désespéré. En revanche, si les données que tu en reçois sont une liste d'éléments, il y a peut-être moyen de t'en tirer en ne stockant la matrice nulle part, mais en reconstruisant au fur et à mesure les coefficients dont tu as besoin. Avec la méthode de Gauss-Seidel, ça doit être possible, mais je n'ai jamais essayé.

Si seulement les profs laissaient leurs étudiants totalement libres de choisir les méthodes qu'ils utilisent ...

Une citation pour te consoler:

« Ici repose la dépouille de Jonathan Swift, D.D., doyen de cette cathédrale, qui désormais n'aura plus le cœur déchiré par l'indignation farouche. Va ton chemin, voyageur, et imite si tu le peux l'homme qui défendit la liberté envers et contre tout. »

Jean-Marc Blanc

[julesu]

Jean-Marc, merci de votre aide et de votre soutien ! Je vais chercher de ce pas du côté de la méthode de Gauss-Seidel.

[Eglantine]

Ce que je pourrais te conseiller c'est d'essayer le stockage morse à la place du stockage bande, il réduit les temps de calculs, et tu n'as plus de zéros qui traînent, ceci étant il faudra faire attention aux calculs que tu changeras pour la méthode, mais c'est très pratique, et ça a donné ses preuves.

[julesu]

Merci Eglantine,
Le stockage bande me semblait la solution la plus naturelle dans mon cas, mais je vais également considérer le stockage morse et voir si celui-ci est facilement applicable à mon code.