Herezh++

petit edit de ce test.

J'ai modifié le fichier .info en pièce jointe pour obtenir correctement un contact entre la bande et la pièce massive. En particulier un plafonnement de la force de contact à 1 N au lieu de 10000 et plus de laxisme sur la pénétration maxi.
jeux de paramètres :

para_contact

CONTACT_TYPE 2
TYPE_PENALISATION_PENETRATION 16
PROP_VALPROPRE_RAIDEUR   0.1
FORCE_CONTACT_NOEUD_MAXI 1.

TYPE_DE_DECOLLEMENT     1
NB_DECOLLEMENT_MAXI     1

PENETRATION_CONTACT_MAXI 1.
PENETRATION_BORNE_REGULARISATION 1.e-2
DISTANCE_MAXI_AU_PT_PROJETE  20.

on obtient une forme en équilibre :

NB : en vrai, le calcul ne converge pas. Il pédale dans le vide avec une précision de convergence qui reste élevée, mais il ne se passe plus rien. Ce point n'est pas le sujet de ce ticket (je ferai un autre ticket car c'est mon pb actuel même avec la version 7.057). Le .info fourni dans ce ticket est de toute façon prévu pour ne pas converger avec une précision demandée exagérément petite égale à 1.e-9.

Cette modif permet de mieux observer la fuite mémoire car maintenant, les zones de contact s'établissent et ne changent plus (à peu près établies vers l'itération 1200 sur 1500).

et désormais voici ce que donne les versions hz++ linux 7.057, 7.064 et 7.065 avec contact ainsi que 7.065 sans contact :

NB : j'ai bien vérifié : il y a bien contact dans le calcul 7.057.

donc la fuite mémoire est due au contact et elle intervient après la version 7.057 et au moins à partir de la version 7.064 (pas testé sur mac).
si ça date de la version 7.064, ça ne concernerait donc pas la récente modif GCC vs LLM ?

faut-il chercher du côté des sorties différenciées (7.060). Je ne pense pas puisqu'ici il n'y a aucune sortie et pas de fuite mémoire sans contact.

en regardant le wiki, je n'ai trouvé que des infos sur la version 7.061 (pas d'infos sur les versions suivantes). Mais tu mentionnes des modif sur le contact :

V 7.061 :
modification du contact.
Un noeud esclave peut-être en contacte seulement avec une facette d'une zone de contact.
- intégration d'une méthode de migration entre 2 éléments de contact
- modifs cosmétiques sur l'affichage d'info liée aux contacts

la partie "intégration d'une méthode de migration entre 2 éléments de contact" parait être une bonne piste à creuser.

Effectivement suite à la mise en place d'une partie "mémorisation" du contact initial, il y avait une dé-allocation qui manquait d'où une consommation de mémoire.
C'est réparé.
Je m'occupe maintenant de comprendre le fct du contact et de la convergence du calcul

ok je clos le ticket et je te laisse ouvrir le nouveau.
De mon coté je vais d'abord mettre à jour les exécutables et les sources !

je viens de tester sur linux en faisant courir sur 3000 itérations. La fuite mémoire est toujours là! mais la pente est moins raide :

Le déroulement du calcul n'est pas changé. La bande trouve une position d'équilibre dès 1000-1500 itérations, puis il ne se passe plus rien.

je vais essayer sur mac

voici le résultat sur mac :

sans surprise, j'obtiens le même comportement que sur linux.
NB : j'ai testé la 7.056 au lieu de 7.057 (pas d'exécutable 7.057 dispo sur mac)

j'avais oublié dans mon message précédent de joindre une nouvelle version du script exe_mesureRAM.py. Il peut maintenant tourner sur mac et linux. Les trois variables à renseigner sont en tout début de script (intervalle de mesure, fichier log à créer, exécutable Herezh).

pour le coup, c'est vraiment de la plomberie!! Trouver et réparer les fuites...
Il y en a qui préfère désormais coder en Rust. Car il repère plus facilement les problèmes de gestion mémoire dès la compilation.

et bien après un rude malaxage de neurones j'espère que j'ai réglé le pb, en fait il y avait 2 pb:
1) un pb nouveau qui résultait de la mise en place de la prise en compte d'un contact qui intégrait l'historique du passage sur plusieurs facettes (suite à une amélioration du contact récente)
2) un pb très vieux !! qui provient de la dé-allocation des matrices carrés. La fuite engendrée n'était pas grande mais compte tenue du fait que ces matrices sont très utilisées....
bref !
nouvelle version V 7.067
NB: super le script pour visualiser l'évolution de la mémoire

parfait sur mac avec cette version 7.067. je testerai sur linux dès que possible.

c'est intéressant de voir en zoomant la libération de mémoire vers 35 s :

pas évident à interpréter. Cette marche correspond à une libération assez importante (23% de la mémoire).
Je serais tenté de discuter de ce point vu ce que j'ai observé mais ça va prendre trop de temps. Le prochain ticket sur la convergence me parait plus utile.

conclusion évidente : il est plus que temps d'ajouter des tests de vérif sur la mémoire.

je viens de tester sur linux et je vais quand même dire des choses, qui sont à mon avis le point final de ce sujet.

Sur linux, j'obtiens également un changement de mémoire par marche, mais au contraire à la hausse de 4% contrairement à la baisse de 23% obtenue sur mac :

le message qui provoque cette marche est strictement le même que sur mac et intervient 3 fois aux mêmes itérations : 745, 746 et 747
le message est :

   change front. du noeud  266 mail= 1 ==   front 3 (dans le type) (FrontTriaLine) de l'EF 4 (TETRAEDRE, LINEAIRE) mail. 2 --> nevez  front 2 (dans le type) (FrontTriaLine) de l'EF 5 (TETRAEDRE, LINEAIRE) mail. 2
   change front. du noeud  38 mail= 1 ==   front 3 (dans le type) (FrontTriaLine) de l'EF 61 (TETRAEDRE, LINEAIRE) mail. 2 --> nevez  front 1 (dans le type) (FrontTriaLine) de l'EF 6 (TETRAEDRE, LINEAIRE) mail. 2

et vu l'affichage terminal, les noeuds se sont déplacés de la même manière entre le calcul mac et linux, aboutissant à la même valeur de critère de convergence, énergie cinétique/interne/externe.

et j'ai envie de dire que là, on touche probablement à la manière différente de gestion de mémoire entre mon mac et mon linux. Le calcul linux a l'air d'ailleurs plus gourmand en mémoire vu les valeurs en ordonnée des graphes (appImage ?).

passons au second ticket