Ce commit est pour récupérer les performances liées aux opérateurs de projection.

Suite à mon commit sur la parallélisation du contact, il y a eu une dégradation dans le temps CPU pour les routines ALE (principalement Etape de Rezoning) et pour des projections sur des outils de contact avec surface de révolution.

Suite à l'utilisation du profiler d'Intel, j'ai pu faire le bilan du temps CPU et constater que l'accès à la position courante des points lors de l'opération de projection était très couteux (lecture de la base de donnée). C'était pour cette raison qu'il y avait l'opération keepPosition(Configuration &conf) et releasePosition(Configuration &conf) à certains endroits dans les opérateurs de projection dans la version précédente optimisée en série. Par cette opération, on stocke un vecteur position qui correspond à la configuration stockée dans chaque point de l'entité géométrique. Cette configuration stockée correspond à “LAST_KEPT” et au numéro 0 dans cette “cache” placée dans chaque point. Si on évalue une position sur une courbe avec cette configuration (qui correspond à la configuration courante par exemple), on va gagner en temps CPU puisque nous ne devons pas lire la position initiale et le déplacement dans la base de donnée pour obtenir la position courante. En résumé, on stocke l’entièreté de la configuration de l’objet géométrique sur lequel on travaille pour gagner du temps CPU puisque les lectures en base de donnée sont très lentes.

Dans l'ALE, ce sont les objects suivants BoundaryReZoner, LastStepReZoner, IterativeReZoner2D et Tm2DReZoner qui furent adaptés pour tenir compte de ce mécanisme.

Dans le ContactInteraction, ce sont les fonctions suivantes initIteration(), endStep() (Mise à jour du point de collement), endALE() (Mise à jour du point de collement, calcul des pressions et cisaillement de contact suite à une évaluation de la normale) et initialise() (Calcul du point de collement), qui furent adaptés pour tenir compte de ce mécanisme.

En ce qui concerne les opérateurs de projection, j'ai ajouté dans le constructeur en plus de l'objet géométrique, la configuration sur laquelle on travaille. Ainsi, on évite d'instancier un opérateur de projection et effectuer une projection d'un point sur deux configurations différentes. Ici, nous devons maintenant placer à chaque fois l'entité géométrique dans la configuration sur laquelle on veut travailler avant d'effectuer les projections.

Afin de gagner du temps CPU, si on n'a pas de point de départ pour calculer la projection d'un point sur une courbe ou sur une surface, j'ai ajouté le test sur le résidu lors du parcours de la grille pour obtenir un point de départ. Si par hasard, on évalue un point de la grille qui correspond à la projection. Dès lors, on stoppe le parcours de la grille puisque nous avons trouvé la solution.

En lisant les routines sur la projection d'un point sur une courbe ou sur une surface, j'ai constaté qu'il serait intéressant de scinder en classe le calcul d'une projection orthogonale et le calcul d'une projection oblique car on effectue des opérations inutiles dans les deux cas.

[a]:
[r]:

[a]:
[r]:

— gaëtan 2016/10/23 21:05