Méthode par défaut de calcul du résidu + divers

Historiquement, le calcul du résidu est fondé sur la méthode 1, dont la normalisation induit une division par le nombre de degrés de liberté. Cette méthode était valide dans le cadre de tests de validation numérique, de tests de la littérature, à déplacements imposé, sur des maillages de quelques dizaines de DDLs (ce qui était accessible à l'époque),…

Malheureusement, cette méthode de normalisation du résidu devient de plus en plus fausse au fur et à mesure que le nombre de degrés de liberté augmente. De longue date, des alterantives ont été implémentées, dont la méthode 4 qui, pour moi, est la méthode via laquelle la normalisation du résidu est la plus indépendante des conditions de calcul (maillage, charge, évolution temporelle,…).

Ayant du, récemment, débugger un test biomedical de Cedric (énormément de DDLs), dont le problème était une fois de plus la méthode de calcul du résidu, j'ai décidé de modifier le défaut …

A partir de ce commit, la méthode de calcul du résidu par défaut est la méthode 4 : $$Residual = \frac{||FreeResidual||}{Rmin}$$

Soit une normalisation :

• ne dépendant que de la charge appliquée (sous tous ses aspects) : $$Rmin = ||FreeExternalForces|| + ||CstrInternalForces||+||CstrInertialForces|| $$
• indépendante du nombre de degrés de liberté
• avec un seuil inférieur au terme de normalisation (limitNormFactor) : si $$ Rmin < limitNormFactor$$ ⇒ $$ Rmin = limitNormFactor $$

voir la page Managing N.-R. Iterations pour plus d'info sur les méthodes de calcul du résidu.

Le frein qui nous a toujours retenu de changer la méthode de calcul du résidu par défaut est la batterie. En effet, changer ce défaut induite :

• soit d'imposer la méthode 1 dans tous les cas tests de la batterie (contre productif à mon avis et dangereux pour les gens qui écrivent leurs jeux de données par mimétisme des tests de la batterie)
• soit de changer le défaut et d'accepter des changements de résultats (principalement de convergence) des tests de la batterie.

La valeur par défaut de la tolérance est restée inchangée à 1.0e-4.

La méthode 4 induisant un calcul de résidu plus restrictif, c'est la seconde option qui a été majoritairement choisie. Pour certains gros tests pour lesquels la tolérance avait été durcie pour contre balancer la division par nbDofs (j'ai vu des 1.0-8, 1.0e-10 même 1.0e-12), j'ai adapté la tolérance pour que ca passe (je n'ai pas étudié en détails toutes les conséquences sur tous les cas tests modifiés, juste le comportement global).

Afin de ne pas perturber certaines méthodes très sensibles (XFEM, Thixo, ….) et ne pas perdre trop de temps de temps à débugger, j'ai réimposé la méthode 1 dans une 50aine de cas tests (en indiquant que c'est pour raison de continuité)

• les XFEMs de Ewen
• les thixos (directe, ale, remaillage)
• Asperity crushing
• …

Au final, plus de 500 tests qui ont des différences sur les TSC_STP et plus de 1000 sur les TSC_ITE (souvent à l'augmentation), mais comme c'est pour un meilleur respect de l'équilibre, je considère que c'est pour un mieux…

Au final, la hausse du temps de calcul total des batteries reste limitée (sur les quelques derniers commits):

Correction de AIC_USER : méthode d'imposition de l'AIC par l'utilisateur Ajout de 2 tests utilisant le AIC_USER

Ajout d'un “mime type” aux fichiers *.py dans les fichiers “Verif.html” de manière à ce que, si votre navigateur est configuré correctement, les fichiers *.py soient ouverts avec EditPadPro (ou tout autre éditeur de texte).

Ajout d'un script timers2CSV.py traduisant les fichiers timers au format CSV, calculant le temps du “reste” (ce qui n'est pas mesuré) et écrit dans un ordre logique…

A utiliser avec l'utiliraire “PostProLoop”

le tests mtExactDataTransfer_CGAL.tests.disk3D_LocMort déconne encore et toujours sous gaston (une fois il marche, une fois pas). Faudra un jour regarder ca …

A       toolbox\timers2CSV.py

A       apps\qs\slidingRd2dEpeUserAreaInContact.py
A       apps\qs\slidingRd3dUserAreaInContact.py

— Luc Papeleux 2017/06/16