- Généralisation du formalisme ALE:
- Le but est de gérer les problèmes de convection de manière générale (multi-élément -> EAS?).
- Pour rappel, en ALE, après chaque remaillage, on effectue un transfert des grandeurs aux points de Gauss (sigma, epl, etc) et des grandeurs nodales (température, vitesses, etc) d'un maillage à l'autre. En général, il y a 2 ou 3 problèmes de convection si on utilise l'élément SRI classique: un transfert de la pression, un transfert des grandeurs déviatoriques et, éventuellement, un transfert des valeurs nodales si le schéma d'intégration le demande. Ses 3 convections étaient codées "en dur" via une superbe enum appelée ConvectionType. La valeur de cette énum était passée un peu partout pour permettre un accès aux valeurs nodales ou aux points de Gauss de manière transparente.
- Pour virer cette enum, j'ai utilisé le polymorphisme du C++ en définissant une classe baptisée Unknown définissant soit une inconnue au point de Gauss (c-à-d un InternalField), soit une inconnue au noeud (c-à-d une inconnue de DB, soit une Lock). J'ai donc les classes LockUnknown et FieldUnknown.
- Pour permettre la gestion de n'importe quel type d'élément (éventuellement non sous-intégré ou même sur-intégré), j'ai défini les classes ConvectionProblem et dérivées. Ces classes définissent un problème de convection (soit nodal soit aux points de Gauss) en associant une liste d'inconnues et un maillage de convection. En prépro, AleMethod recherche tous les problèmes de convection différents à résoudre avec leurs variables associées et les stocke. Dans le cas d'un problème non SRI, le problème "volumique" ne sera donc pas trouvé et la convection ne sera pas effectuée.
- Il fallait enfin détecter les différents problèmes de convection. Pour ce faire, j'ai revu la structure d'accès aux valeurs de points de Gauss (ancienne routine pourrie nb_alefield). Grâce aux récents développements de Luc et Ludo dans l'élément, c'est devenu faisable (j'irais pas jusqu'à dire simple): L'idée est la suivante:
- pour chaque élément, on boucle sur ses intégrateurs.
- pour chaque intégrateur, on détermine le nbre de points de Gauss et on demande a l'élément ses variables "ALE". L'élément transmet la demande à sa méthode l'intégration.
- La méthode d'intégration demande la liste des valeurs au matériau (à ce stade, un SRI ou un EAS répondent la même chose). La méthode d'intégration fait alors le tri en fonction du numéro d'intégration (l'intégration SRI va ainsi écarter la pression des variables dévriatoriques).
- Autrement dit, au stade "prépro", aucun accès aux points de Gauss. Les points de Gauss n'ont plus la possibilité de retourner le nombre de champs qu'ils stockent (ancien nb_ale_field). Ca renforce le caractère "structure de stockage" du GPState (toutes les valeurs définies ne sont pas spécialement utilisées - cfr pt de Gauss volumique du SRI).
- Lors de l'exécution des schémas de convection, l'accès aux valeurs se fait directement sur le point de Gauss en passant l'InternalField correspondant (récupéré au travers de la classe FieldUnknown).
- Nouveaux noms: les classes MachinConvection ont été renommées MachinConvector.
- Séparation des opérations de rezoning et de convection dans la classe AleMethod: création des classes ConvectionStep et RezoningStep.
Fichiers supprimés:
mtAle/Convection.*
mtAle/ConvectionType.*
mtAle/GodunovConvection.*
mtAle/LinearRecConvection.*
Fichiers ajoutés:
mtAle/ConvectionProblem.*
mtAle/ConvectionStep.*
mtAle/Convector.*
mtAle/FieldUnknown.*
mtAle/GodunovConvector.*
mtAle/GPConvectionProblem.*
mtAle/LinearRecConvector.*
mtAle/LockUnknown.*
mtAle/NodalConvectionProblem.*
mtAle/ReZoningStep.*
mtAle/Unknown.*
