Rien
Modifications
- J'ai renommé State en LocalState. Il faudra prochainement essayer de supprimer la Lock TM du State et de la DB (idéalement, il faudrait identifier le temps différemment - c'est pas un dof). Pour l'instant c'est pas faisable facilement.
Fichiers ajoutés/supprimés
Ajout de LocalState et suppression de State dans oeKernel
Gestion sans restart de différentes phases de calcul
Je viens de commencer l'implémentation des "phases" de calcul dans metafor sans restart. Il s'agit d'améliorer la définition des intervalles de temps pour permettre des modifications plus profondes de la structure du cas test que le changement du "mulm". Le travail n'est pas terminé mais je note ici mes idées (si vous en avez d'autres à ce sujet, n'hésitez pas à me le dire)...
Ce travail permettra à moyen terme d'aborder l'ajout/suppression d'éléments/noeuds/CL et donc plus tard, le remaillage (il suffira d'avoir des remailleurs et des algos de transfert - la structure de l'intégrateur, des données et du fac sera, elle, déjà prête).
A l'instar d'Abaqus, l'utilisateur pourra définir une suite d'instants (appelés Step dans Abaqus - j'ai choisi Stage pour Metafor vu que nos Steps sont les incréments Abaqus) qui vont délimiter des différentes étapes du calcul. Dans un premier temps, les Stages seront définis à l'aide des commandes setInitialTime et setNextTime traditionnelles. Plus tard, il sera possible de les définir explicitement.
Après la définition des Stages , il sera possible, lors du passage de Stage, de:
- activer ou désactiver une classe : cette fonction sera programmée via une nouvelle classe nommée Activable. Les objets pouvant être activés et désactivés devront implémenter cette interface. L'utilisateur pourra ainsi désactiver, par exemple, l' Interaction de contact no 5 lors du passage au Stage 2 en mettant dans son jeu de données intset(5).deactivate(stages(2)). Lors du passage d'un stage, l'intégrateur de Metafor, informera les objets du passage et leur demandera de se mettre à jour. Il sera ainsi possible de mettre à jour la liste des éléments, les degrés de libertés, etc et de continuer le calcul avec la nouvelle configuration du problème. Les classes Interaction, Fixation, Loading, etc seront toutes des Activables.
- modifier un objet ou une valeur : le but est de changer des valeurs réelles de manière discontinue (par exemple, changer la densité de la structure d'une étape à l'autre, changer la prof de contact, changer la tolérance de N.-R., etc) ou des valeurs entières enums ou bool (par exemple, le type d'intégrateur). Ceci sera une extension du cas précédent: la valeur dépendant du temps sera gérée par une nouvelle classe : StageDepValue<T>. C'est une liste de valeurs associant une valeur à un Stage (la classe Activable utilise un StageDepValue<bool> pour activer l'objet qui en dérive).
Modifications
- Possibilité de démarrer un test en t0!=0 (il y avait un bug décelé par les étudiants). J'ai modifié cont2 pour qu'il démarre en 1 et se termine en 2.
- Création des classes Stage, StageManager, Activable et StageDepValue<T> pour le changement d'étape de calcul sans restart (voir ci-dessus).
- stupidMaterial2D et 3D ont été regroupés en stupidMaterial.
Fichiers ajoutés/supprimés
Ajout de Stage, etc dans mtKernel
