Discussion :

[genteur slayer]

je suis bien d'accord avec le changement d'algo
ou le changement de machine.

cependant il est vrai que ces deux solution peuvent être coûteuse (en temps ou en monnaie) et, si j'ai bien compris, bobbyboy ne veut pas ces solutions!

donc pour redéfinir allocate, tu lui donne simplement un autre nom...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
 
module TABDATA
implicit none
real(kind=8),dimension(:),allocatable :: U
integer Taille_U
integer Unit_U
integer,parameter :: Taille_Max=2048000000
 
interface
 
  subroutine allocation(Taille)
   implicit none
   integer,intent(in) :: Taille
  end subroutine allocation
 
  function Get_U(i)
    implicit none
    integer,intent(in) :: i
    real(kind=8) Get_U
  end function Get_U
 
  subroutine Set_U(i,x)
  implicit none
    integer,intent(in) :: i
    real(kind=8),intent(in) :: x
  end subroutine Set_U
 
end interface
 
end module TABDATA
 
 
subroutine allocation(Taille)
  implicit none
  integer,intent(in) :: Taille
  Taille_U=Taille
  if (Taille>Taill_Max) then
    Unit_U=15
    open(unit=Unit_U,access=direct)
  else
    Unit_U=0
    allocate(U(Taille_U))
  end if
end subroutine allocation
 
function Get_U(i)
  implicit none
  integer,intent(in) :: i
  real(kind=8) Get_U
  if (Unit_U==0)then
    Get_U=U(i)
    return
  else
    read(Unit_U,rec=i)Get_U
    return
  end if  
end function Get_U
 
subroutine Set_U(i,x)
  implicit none
  integer,intent(in) :: i
  real(kind=8),intent(in) :: x
  if (Unit_U==0)then
    U(i)=x
    return
  else
    write(Unit_U,rec=i)x
    return
  end if  
end subroutine Set_U

ou quelque chose comme ça...

[bobbyboy]

Mais pour ça, il fallait mailler judicieusement!

Mes maillages sont déja limite très grossier ...
j'essaye d'avoir une finesse "correcte" là où :
- l'écoulement est très turbulent
- l'écoulement présente de fort gradients

Mais sinon aux endroits où l'écoulement est régulier, le maillage est très grossiers (à tel point que je me demande si la formulation intégrale des eq de Navier-Stockes ne fausse pas completement mes résultats)
Mais bon, les résultats que j'ai obtenus sur des écoulement standard bien connus (type Poiseuille) ne sont pas abérrants.

[bobbyboy]

Merci genteur slayer,

Je testerai ça ce weekend

[genteur slayer]

tout dépend de comment tu calcul à l'intérieur d'une maille:
je suis tout à fait capable de modélliser l'écoulement turbulent 3D autour d'un profil d'aile avec une seule maille... cela dit la formulation derrière est vellue!!!

les modèles de turbulence servent à ça d'ailleur: modélliser les dissipation d'énergie à l'intérieur de la maille. en rafinant tu rend moins sensible ton calcul au modèle de turbulence puisque NS te calcul déja la turbulence. grosso modo si tes "tourbillon" sont plus grand que la maille => pas besoin de modèle de turbulence (bon c'est schématique bien sûr)

n'oublie pas que dans la MEF ou la MVF tu cherche une solution faible au problème, il y a déjà une approximation à ce niveau, et il est inutile de chercher à augmenter la précision des algos au delà de la limite de modélisation...

bien penser aussi à réduire le domaine de calcul au maximum!!! mieux vaut une condition limite particulière que plein de maille pour la simuler par exemple. utiliser les symétries etc...

bien se demander quels variable sont indépendantes... par exemple certain vont considéré que la pression est dépendante de la vitesse et peut être retrouver simplement avec le div(U)=0 donc on ote cette variable... c'est un exemple mais il y a des tas d'astuces comme cela...

[FR119492]

Salut!

Tout l'objet du sujet est : comment faire ça?

Tout d'abord, tu dois faire un choix en ce qui concerne la méthode que tu utiliseras pour résoudre des systèmes linéaires: tu peux prendre soit une méthode itérative, comme celle de Gauss-Seidel, soit une méthode directe.
Dans le premier cas, il est souvent plus avantageux de reconstruire la matrice à chaque itération plutôt que de la stocker. Dans le second, tu dois examiner si ta matrice possède des propriétés particulières: par exemple, si elle est symétrique définie positive, en utilisant la méthode de Cholesky, tu économises la moitié de la place en mémoire et la moitié du temps de calcul.
D'autre part, les méthodes des éléments finis et apparentées conduisent à des matrices très creuses; il est inutile de gaspiller de la place à stocker des coefficients identiquement nuls et du temps à calculer A*0=0 et A+0=A. Une conception judicieuse du maillage permet des économies substantielles.
Enfin, si tout ça ne suffit pas, il faudra faire marcher notre imagination et inventer autre chose.
Jean-Marc Blanc

[DaZumba]

donc pour redéfinir allocate, tu lui donne simplement un autre nom...

Pour utiliser la memoire virtuelle, il me semble preferable de laisser le systeme d'exploitation faire. C'est son boulot apres tout...

[bobbyboy]

Bon,
j'ai encore une fois agrandi la partition swap et le maillage que je voulais passe nikel.
A cause de l'accès au disque l'ordi se fige très souvent mais le but n'est pas de travailler dessus en même temps que le code tourne.

L'allocation statique proposée par genteur slayer a le même effet.

[genteur slayer]

par expérience, je laisse l'os le moins libre possible dans mes prog pour plusieurs raison:
- portabilité: si tu change d'os ton code marche encore.
- stabilité: en particulier sous windows en ce qui concerne la gestion mémoire
- code autonome
- on gère mieux les événement, c'est à double tranchant: il faut bien tous géré...
...

[Leflix]

Une petite précision :
pour les codes de méca solide, c'est à peut près le même problème voir pire. En effet tu ne peux pas te passer de ta matrice de rigidité qui fait nb_maille*nb_maille >> nb_maille*nb_composantes (en meca flu)

Le problème reste inchangé, tu es obligé de déclarer des tableaux enormes.


Pour faire des volumes finis (ou éléments fini) , j'en connais pas !

Je viens de tomber sur cette discussion qui date un peu, mais les informations parfois apportées sont parfois tellement sidérantes que je peux difficilement rester muet...

Si tu fais du compressible et que tu adoptes un schéma en temps explicite, tu n'as AUCUNEMENT besoin de matrice de quoi que ce soit à stocker.
De toute manière même en cas de schéma implicite, on ne stocke que les coefficients non nuls de ta matrice. ce qui au passage t'oblige à utiliser des méthodes de résolution de systèmes linéaire itératives. Si tu utilises des schémas de discrétisation centrés d'ordre deux, cela te donnera des schémas à 5 points, donc 5 diagonales à stocker...donc 5 variables supplémentaires.
mais bon c'est une autre histoire...
Utilise donc un schéma explicite et là tu n'auras à stocker que tes 6 variables (U,V,P,T,RO,E).
Si tu as un maillage 10000x10000 ca fait 400 MO par variable si tu es en simple précision ou 800 MO si tu es en double précision.
donc soit tu restes en simple précision, ce qui fait 6x400MO = 2.4GO la ça passe. sinon en double effectivement ça fait 4.8GO et la tu dépasses ta RAM.

Tout ceci étant dit pourquoi as tu besoin de maillages si fins en 2D en plus?
Je n'imagine pas comment tu feras le jour où tu voudras passer en 3D !!
Tu as 100 millions de noeuds en 2D !!! ceux qui arrivent à faire 100 millions de noeuds en 3D c'est déjà très très bien ! ca permet de simuler en DNS (simulation directe) 3D des écoulements à Re=3593 et peu de gens arrivent à faire cela...question de moyens
Donc soit tu modélises la turbulence avec des méthodes RANS ou LES car moins nécessiteuses en points de calculs, soit tu achètes une machine plus puissante pour augmenter ta RAM et ta vitesse de calcul aussi..., soit tu baisses ton nb de Reynolds...
Il n'y a pas d'autres solutions !!!

Et puis la RAM c'est une chose, mais ensuite combien de temps prend ton calcul? 3 mois pour 25 itérations en temps?