Avec le schéma d'intégration de Chung Hulbert, l'équation d'équilibre fait intervenir les forces au pas de temps courant mais aussi au pas de temps précédent (appelées forces résiduelles). Lors du transfert de données, ces forces résiduelles étaient perdues ce qui induisait une erreur parfois conséquente dans le rééquilibrage.

A présent, ces forces peuvent également être transférées, à condition de les enregistrer dans la DB. Afin de ne pas réduire les performances globales, ces forces ne seront calculées et enregistrées en DB qu'à la fin de l'intégration, et à condition d'avoir indiqué dans le cas test l'option :

metafor.setDynamicRemeshing(True)

Dans ce cas où ces forces sont calculées et transférées, le rééquilibrage a pour objectif de vérifier l'équation d'équilibre

$$(1-\alpha_M) \boldsymbol{F}^{\text{inert}}(t^{n+1}) + (1-\alpha_F) \boldsymbol{F}^{\text{int}}(t^{n+1}) + \boldsymbol{F}^{\text{res}}(t^n) = (1-\alpha_F) \boldsymbol{F}^{\text{ext}}(t^{n+1})$$

Si cette équation n'est pas vérifiée directement, on procède par étapes en appliquant une portion du déséquilibre des forces en tant que forces externes :

$$\boldsymbol{F}^{\text{ext}}(t^{n+1}) = (1-\beta)\boldsymbol{F}^{\text{ext}}(t^{n+1}) + \beta \boldsymbol{F}^{\text{int}}(t^{n+1}) + \beta \frac{1-\alpha_M}{1-\alpha_F}\boldsymbol{F}^{\text{inert}}(t^{n+1}) + \frac{\beta}{1-\alpha_F}\boldsymbol{F}^{\text{res}}(t^n)$$

et on itère jusqu'à ce que l'équation d'équilibre soit vérifiée pour $\beta = 0$

Différents cas-tests ont été ajoutés pour vérifier cette procédure, notamment dans le cas où le maillage est simplement copié.

Une tentative d'automatisation est introduite dans ce commit. Différentes fonctions ont été définies dans toolbox.remeshingUtilities pour que l'appel à une seule fonction permette de remailler, transférer les données, rééquilibrer, et rende un objet metafor prêt à reprendre la simulation. Cette procédure a été développée quand j'attendais l'accès aux batteries, sa robustesse n'a donc pas été testée et elle risque donc d'être modifiée. Sa description fera l'objet d'un commit ultérieur.

En AIC_ONCEPERSTEP, l'aire de contact est calculée au début de chaque pas de temps. Son calcul est censé être réalisé sur base des valeurs de déplacements qui se trouvent dans le GP1. Cependant, le calcul était réalisé juste après avoir switché les GP0 et GP1, donc le calcul se réalisait sur base du GP0. En temps normal, cela induit juste une petite erreur, cependant lors d'un restart le GP0 n'a pas été initialisé, donc l'aire de contact était entachée d'une sérieuse erreur. Ceci est une des raisons pour laquelle le redémarrage patinait autant après remaillage.

Les cas tests contenant les mots “NullRemesh” sont là pour tester remaillage et rééquilibrage dans le cas où le maillage est simplement copié d'un metafor à l'autre. Cela permet de vérifier que le rééquilibrage se fait de façon (presque) immédiate, étant donné que la situation remaillée est la même que la situation de départ.

La série “forgeQS” vérifie cela pour le schéma quasi-statique, la série “forgeDyn” pour la dynamique lente, et la série “beamBendingDyn” pour la dynamique plus rapide.

A : 
R : 

A : apps.remeshing2.beamBendingNullRemeshDyn_1.py
A : apps.remeshing2.beamBendingNullRemeshDyn_2.py
A : apps.remeshing2.beamBendingNullRemeshDyn_3.py
A : apps.remeshing2.beamBendingNullRemeshDyn_4.py
A : apps.remeshing2.forgeNullRemeshDyn_1.py
A : apps.remeshing2.forgeNullRemeshDyn_2.py
A : apps.remeshing2.forgeNullRemeshDyn_3.py
A : apps.remeshing2.forgeNullRemeshDyn_4.py
A : apps.remeshing2.forgeNullRemeshQS_1.py
A : apps.remeshing2.forgeNullRemeshQS_2.py
A : apps.remeshing2.forgeNullRemeshQS_3.py
A : apps.remeshing2.forgeNullRemeshQS_4.py
A : apps.remeshing2.forgeRemeshDyn.py
R : 

— Pierre Joris 2015/03/13