Metafor

Ce commit a pour but principal de réécrire mes algos pour espérer augmenter leur espérance de vie et limiter leurs entretiens.

Par exemple, concernant mon schéma de rééquilibrage BalancingQuasiStaticTimeIntegration, je m'étais en gros basé sur QuasiStaticTimeIntegration et sur l' initialBalancing, réalisant des bons gros copier-coller et modifiant juste le nécessaire.

Evidemment, rien que sur les quelques mois depuis son écriture, ces différents fichiers ont déjà pas mal divergé, conduisant à une n+1ème branche morte qui risquait de pourrir de plus en plus, jusqu'à ce que plus personne (sauf le très courageux Luc !) n'ose se plonger dedans.

J'ai donc essayé de réécrire ça plus proprement, en dérivant un maximum des fonctions existantes et ne modifiant que le strict minimum.

J'ai fait la même chose entre toolbox.remeshingUtilities et toolbox.utilities pour les fonctions cleanWorkspace et vizu.

J'ai remarqué que les forces d'inertie n'étaient pas recalculées après le remaillage-transfert de données. Je suis presque certain que ça l'était précédemment, mais visiblement, mes différentes modifs ont dû perturber ça. Maintenant c'est recalculé. J'ai rajouté des cas-tests où la partie inertie joue beaucoup pour contrôler ça : beamBendingDyn2DRemeshing, beamBendingDyn3DRemeshing, et forgeDynFastRemeshing.

J'ai remarqué que, dans le cas quasi-statique, après remaillage, le “stepPredictor” sur base des vitesses transférées était parfois plus mauvais que sur base de vitesses nulles. J'ai donc mis ça en option, on peut maintenant, lorsqu'on définit des options de rééquilibrage choisir si on souhaite conserver les vitesses ou non. Par défaut on transfère donc les données, mais l'utilisateur averti pour désactiver ça (ce qui revient en gros à mettre EXTRAPOLATION_ZERO pour le premier pas de temps).

A : 
R : 

A : apps.remeshing2.fullAuto.beamBendingDyn2DRemeshing
A : apps.remeshing2.fullAuto.beamBendingDyn3DRemeshing
A : apps.remeshing2.fullAuto.ForgeDynFastRemeshing
R : 

— Pierre Joris 2016/05/23