Au commit 1992, il a été mis en avant que, pour une simulation lagrangienne d’un modèle de profilage de grande taille, la gestion des interactions de contact était responsable d’un large écart de performances en termes de temps CPU. Le temps d’horloge était en effet réduit de 61 % en faveur de la gestion dynamique des interactions. La comparaison des 2 diagrammes de répartition du temps CPU a mis en évidence que ce gap de performances ne provenait pas seulement de la détection du contact mais aussi du calcul des forces internes, externes, d’inertie et de la matrice de raideur.

L’objectif de ce commit est double : d’une part, réduire à nouveau le temps de calcul des simulations et d’autre part refermer le gap de performances entre les 2 modes de gestion des interactions de contact du modèle de profilage lagrangien.

Pour ce faire, les opérations d’assemblage de Metafor sont optimisées en éludant les contributions d’assemblage nulles. Les opérations d’assemblage sont donc limitées aux seules contributions non-nulles.

Les routines d’assemblage de forces de Metafor sont écrites de manière très généraliste. L’assemblage des vecteurs de forces internes, externes et d’inertie est en effet réalisé dans un tronc commun dans le code source. Outre les forces externes d’un élément de contact, il est ainsi possible de demander des forces d’inertie ou internes d’un élément de contact et d’en réaliser l’assemblage dans les vecteurs structuraux. Or, ces derniers sont nuls et l’assemblage de vecteurs nuls est une opération inutilement coûteuse en temps CPU.

Toutefois, dans les routines d’assemblage des vecteurs de forces et de la matrice de raideur, on peut remarquer que l’assemblage n’est réalisé que si l’élément a des forces. Pour ce faire, l’élément interroge la méthode hasForces().

Auparavant, un élément répondait à la question hasForces par le booléen vrai. Pour le cas particulier d’un élément de contact, la réponse était fonction du type d’interaction de contact. Deux cas étaient possibles. Dans le cas d’interaction de contact de type défo-défo ou self contact, la réponse était donnée par le flag de contact. Dans le cas d’interactions de contact de type rigide-défo ou rigide-défo piloté en forces, la réponse était toujours vrai.

Désormais, la dépendance au type d’interactions de contact est éliminée. Un élément de contact répond à la question par le booléen du flag de contact. Grâce à cette modification, les assemblages pour des éléments de contact d’interactions rigide-défo et rigide-défo piloté en forces sont esquivés s’ils n’ont effectivement pas de forces.

Outre la méthode hasForces() au niveau élémentaire, je l’ai ajoutée à un niveau supérieur, c’est-à-dire au niveau de l’interaction. Dans le cas général d’une interaction, la réponse apportée est toujours vrai. Dans le cas d’interactions de contact, la réponse est fonction du type de forces demandées. Si les forces demandées sont des forces externes ou dissipatives, alors la réponse est vraie. Dans le cas contraire, la réponse est faux.

La méthode hasForces() a aussi un usage autre que celui d’éviter des assemblages inutiles. Elle est utilisée en effet pour la connectivité des ddls (méthodes build() de StrMatrixBase et fillElements() de ConnexionBuilder).

La modification de la méthode hasForces() n’était pas sans conséquence pour la connectivité des ddls dans le cas d’interactions de contact rigide-défo piloté en forces. Plutôt que de renvoyer toujours vrai par la méthode hasForces() pour ce type d’interaction et ainsi perdre les bénéfices de temps CPU, j’ai traité explicitement ce cas dans les méthodes build() de StrMatrixBase et fillElements() de ConnexionBuilder.

En bref, l’assemblage est à présent éludé :

• au niveau de l’interaction pour le calcul des forces internes et d’inertie si l’interaction est de type contact.
• au niveau élémentaire pour le calcul des forces externes et de la matrice de raideur si l’élément est un élément de contact pour lequel aucun contact n’est détecté.

Les modifications de ce commit apportent un gain indéniable sur le temps de calcul des simulations lagrangiennes de profilage. Pour le même cas-test de profilage que les précédents commits, le temps d’horloge est réduit globalement de 29 % avec une gestion dynamique des interactions de contact. Conformément à nos attentes, le gain est concentré sur le calcul des forces externes, d’inertie et internes et sur le calcul de la matrice de raideur. De plus, on remarque que les secteurs relatifs au temps d’horloge passé dans les routines de calcul des forces internes et d’inertie sont désormais plus petits que celui du calcul des forces externes. Auparavant, le temps de calcul des forces affichait une répartition quasiment égale entre les forces internes, externes et d’inertie.

Assemblage original

Assemblage modifié

En ce qui concerne le gap de performances entre les deux modes de gestion des interactions de contact ‘byRoll’ du modèle de profilage lagrangien, celui-ci est bien réduit. Grâce à l’effet combiné des boîtes gigognes et des modifications opérées dans ce commit, le gap passe en effet de 61 % à 35 % (cf. diagramme ci-dessous). Les performances sont donc en demi-teinte : la réduction du gap est appréciable mais ce dernier reste élevé et plus grand qu’attendu. Il pose à nouveau question. Les performances en termes de temps CPU restent donc à ce jour lourdement émaillées par le nombre important d’éléments de contact dans les simulations lagrangiennes de profilage.

Gestion non dynamique des interactions de contact 'byRoll'

Gestion dynamique des interactions de contact 'byRoll'

Dans le cadre de la batterie, on a pu remarquer des temps CPU erratiques sur thorgal. Ils sont listés ci-dessous avec un tri selon la différence absolue de temps CPU.

— Yanick Crutzen 2014/07/10