Voila...

Donc tu veux résoudre:

$-\Delta U + \Lamba U =f$
avec tes conditions aux limites qui sont standard.

Il n'y a pas de réponse unique, mais voila quelques éléments:

a) si ton domain est un rectangle ou un paralélipipède, discrétisé en
différences finies avec un pas constant, le mieux *et de loin* ce sont
les routines de Fishpack (cout en mn logm en 2d et mem genre en 3d).
C'est du vieux, du tres tres vieux fortran (meme pas 77!) mais c'est
fabuleux. J'ai une version en real* 8 (==C double) si tu es interessé.
Ca s'interface facilement avec du C, du C++ du Python etc..

b) le multigrille: ce n'est simple à implémenter que dans des cas
voisins de a) et tu auras du mal à trouver un truc tout fait qui marche
bien.

c) résoudre le système linéaire (stocké avec une structure "sparse") ;
finalement c'est une alternative facile a utiliser et très performantes
si tu utilises des méthodes *modernes*:
i) si la taille mémoire est suffisante, autant utiliser une méthode
directe: superLU ou plus moderne Mumps. Mais attention, un laplacien
discrétisé 100x100x100 ne passe pas avec superLu sur ma machine à 16go!
En dimension 2, où les matrices sont moins pleines, ca tourne sans pb
avec 250 000 inconnues.
ii) méthodes iteratives: il faut utiliser les méthodes *récentes*, par
exemple:
*ARMS : développée par Y Saad *LE* spécialiste (je n'ai pas testé);
* La méthode Algébrique Multigrille de Y. Notay (Univ Libre
Bruxelles, téléchargeable sur sa page web). Un Laplacien 100x100x100 se
résout en 10 secondes sur un Optéron à 2.5 Ghz. et la taille mémoire est
hyper faible (< 3 fois le nombre d'inconnues). C'est peu battable à
l'instant présent. L'Algebraic Multigrille généralise le multigrille à
des matrices "quelquonques", mais c'est une autre histoire.

N'hésite pas à me recontacter!


t.d.

--
Thierry Dumont. Inst. C. Jordan (mathématiques)
Univ. Lyon 1 et CNRS.

Nico a écrit :
> Salut,
>
>
> je reviens sur un précédent thread : (gros systeme linéaire 28/02/08,
> créé par moi même)
>
> J'ai toujours le même systeme a résoudre :
>
> Soit B(x,y) et S(x,y)à deux champs vectoriels 2D (espace) à trois
> composantes :
>
> Bx(x,y), By(x,y), Bz(x,y)
> Sx(x,y), Sy(x,y), Sz(x,y)
>
> Les deux quantités sont reliées par :
>
> S(x,y) = B(x,y) - d^2*Laplacien(B(x,y))
>
> Le tout défini sur une grille rectangulaire Lx*Ly, a pas d'espace
> uniforme suivant les deux directions, dx et dy.
>
>
> J'ai les conditions limites suivantes :
>
> bord gauche et droit (x=0 ET x=Lx, y)
> -----------------------------------------------
> Bx(0,y) = Bx(Lx,y) périodique
> By(0,y) = By(Lx,y) périodique
> Bz(0,y) = Bz(Lx,y) périodique
>
>
> Bord inférieur (x, y=0)
> ------------------------------
> dBx/dy(x,0) = 0 (Neumann homogene)
> By(x,0) = 0 (Dirichlet homogene)
> dBz/dy(x,0) = 0 (Neumann homogene)
>
>
> bord supérieur (x, y=Ly)
> -------------------------------
> dBx/dy(x,Ly) = 0 (Neumann homogene)
> By(x,Y) = 0 (Dirichlet homogene)
> dBz/dy(x,Ly) = 0 (Neumann homogene)
>
>
>
> Il semble qu'une bonne façon de résoudre ce probleme est l'utilisation
> des méthodes multigrilles. J'ai lu un peu a propos de ces méthodes, j'ai
> compris qu'elles servent à accélerer la convergence des méthodes de
> relaxation en amortissant les modes basse fréquences de l'erreur via
> l'utilisation d'une grille plus grossiere.
>
> Cependant, vu la multitude apparente des méthodes (quel cycle ? combien
> de grilles ? quelle méthode de relaxation ? etc..?) j'aurais besoin
> d'aide pour déterminer l'algorithme approprié (en terme de rapport
> rapidité/facilité de codage) a la résolutionn de mon probleme.
>
>
>
> Merci

Nicolas Bonneel a écrit :
> Thierry Dumont a écrit :
>> c) résoudre le système linéaire (stocké avec une structure "sparse") ;
>> finalement c'est une alternative facile a utiliser et très
>> performantes si tu utilises des méthodes *modernes*:
>> i) si la taille mémoire est suffisante, autant utiliser une méthode
>> directe: superLU ou plus moderne Mumps. Mais attention, un laplacien
>> discrétisé 100x100x100 ne passe pas avec superLu sur ma machine à 16go!
>
> Salut,
> Je ne comprend pas trop : une matrice pleine comme celle là serait de
> taille 1million par 1million donc bcp trop gros... mais en stockage
> creux, même si tu as 100 elements non nuls par ligne ca ferait dans les
> 100millions de flottants à stocker soit moins d'1Go.
> 3 fois plus pour un champs de vecteurs 3D, mais bon...
>
> A moins qu'il y'ait plus de 500 non nuls par ligne, je vois pas ce qui
> se passe :s
>

Dans une discrétisation différence finies/elements finis/volumes finis,
l'intéret, c'est que la matrice est toujours tres creuse: en différences
finies "classiques", ca veut dire 5 coeffs non nuls seulement par lignes
en dimension 2 et 7 en dimension 3 (pour l'équation de
Poisson/Helmoltz). La matrice du laplacien 3d différences finies
considérée a donc seulement 100x100x100x7 coeffs non nuls et les
structures de données préservent cette "sparsity".

Les méthodes itératives n'utilisent que des produits matricexvecteur
sont forcément moins couteuse en mémoire que les méthodes directes qui
sont toutes basées sur des avatars (astucieux!) de la décomposition LU,
laquelle crée des termes non nuls: le nombre de termes non nuls de L et
U est grand par rapport au nombre de termes non nuls de la matrice, meme
avec une renumérotation astutieuse des inconnues. Mais si on a assez de
mémoire les méthodes directes ont l'avantage d'avoir un compte
d'opérations qui ne dépend que de la structure de la matrice (et pas de
son conditionnement).

Si tu utilises des méthodes spectrales (polynomes de Legendre par
exemple), tu auras naturellement des matrices pleines...

Voila
t.