Herezh++

Bonjour Julien,
comme évoqué entre nous, la raison du non-fonctionnement de l'algorithme est le fait que l'algorithme de Gibbs ne peut pas s'appliquer lorsqu'il n'y a pas des groupes de noeuds sans dépendance entre eux.
Par contre ce qui est dommage dans cette histoire c'est qu'une rupture momentanée de dépendance via l'effacement de contact par exemple, conduit à l'arrêt définitif du calcul... ce qui est ton cas.
Or l'optimisation de la numérotation est vraiment nécessaire avec le contact, car celui-ci induit des relations linéaires qui peuvent conduire à des matrices anormalement surdimensionnées.
donc donc... j'ai cherché à neutraliser momentanément la renumérotation en cas de rupture de dépendance, de façon à ce que le calcul continue avec la numérotation en cours, puis dès que le calcul d'un arbre complet de dépendance est possible, la renumérotation se remet en route.
Sur l'exemple cela fonctionne du début à la fin, donc ça c'est bien.
Par contre le contact est bizarre: on a un collage sur la partie centrale ?? bon... mais ce serait l'objet d'un autre ticket.
Donc pour la renumérotation: à essayer: version V 6.993

Oui, c'est un sujet que l'on avait déjà évoqué.
Initialement, le fait d'avoir des options permettait de bien montrer l'impact de l'option. C'était (et c'est toujours) intéressant au niveau de l'enseignement. Par contre c'est vrai que ce n'est pas le choix par défaut. Dans la même veine l'ensemble des paramétrages par défaut n'est pas toujours optimal.
Au fil du temps je me suis aperçu qu'il y avait néanmoins un intérêt à conserver les options: moins on utilise d'option complexes, plus on diminue le risque de bug. Par exemple, la partie optimisation de la numérotation avec ou non, conservation de la numérotation initiale est pour une opération complexe pour moi en particulier dans le cas où on a plusieurs maillages, du contact, des conditions linéaires, de la dynamique éventuellement, du choix du type de matrice retenue, de la méthode de résolution etc. ce ticket en est l'exemple.
C'est subjectif...
Du coup, pour l'instant (par simplicité) je propose de laisser en l'état c-a-d que nombre d'options sont optionnelles. Rien n'empêche l'utilisateur d'introduire progressivement des options.
Néanmoins, ce serait effectivement intéressant d'introduire un guide de pratiques pour les cas courants, ou des cas complexes particuliers qui sont utiles à garder en tête.
Dans tous les cas, les infos sont disponibles dans la doc.
De plus il est clair qu'Herezh ne peut pas rivaliser avec un code industriel utilisé et donc validé par un grand nombre d'utilisateurs et maintenu par des dizaines de développeurs. Dans ce type de code, les nombreux test de validations permettent de choisir les paramètres optimum. C'est pas le cas d'Herezh.
Ceci étant à voir dans la suite de la vie open source d'Herezh...