Nettoyage de Materset et Material : certaines routines
n'avaient rien a faire là. Il s'agissait de ini_set_step(),
par exemple.
L'initialisation des Matériaux est maintenant faite dans Domain::build()
grâce à la nouvelle routine Materset::initialize()
et Material::initialize(). Les Meta_material redéfinissent
cette méthode virtuelle pour faire l'équivalent de feu ini_set_step().
Remplacement de la variable statique creation_flag_elem de chaque
élément en once_flag. Metafor::ini_set_step()
devient alors Metafor::clear_once_flag(). Cela permettra de symétriser
le traitement des éléments et des matériaux Metafor.
Pour rappel, cette routine permet d'initialiser les variables statiques utilisées
comme invariants lors d'un pas de temps (initialement) ou d'une itération
(depuis l'introduction des dépendances en t et dt - viscosité).
Il est maintenant impossible de faire un begin_step() ou set_step()
sans appeler clear_flag_elem() (anciennement ini_set_step())
Modification des algorithmes (meta_qs, etc) en conséquence.
Modification de VizWin pour diminuer les problèmes de
conflits entre les threads. Normalement, les threads VizWin et
le thread de calcul ne devraient jamais interagir négativement (c'est-à-dire
planter) ; par contre, il reste un risque au niveau de BWin. En
effet, la fonction update() de BWin demande à
VizWin de se mettre à jour instantanément. Il est
donc possible que VizWin mette à jour ses structures VTK
pendant que le thread de calcul fait par exemple un set_step().
Et là, c'est, en général, pas très bon. La solution
serait de définir des zones dans la routine de calcul ou un update()
peut-etre effectué (par exemple lors de l'inversion de la matrice de
raideur en implicite) histoire que tous les threads soient gentils les uns
avec les autres. Une autre solution est de ne pas toucher à BWin
au cours du calcul.
