commit:2008:09_24
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
commit:2008:09_24 [2008/09/24 09:51] – created papeleux | commit:2008:09_24 [2016/03/30 15:23] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== Commit 2008-09-24 ===== | ||
+ | * Nettoyage du contact (very first step) | ||
+ | |||
+ | ===== Problème ===== | ||
+ | * Le contact est affiché comme un de nos points forts Mais | ||
+ | * Les routines sont illisibles | ||
+ | * Il y a un gros mélange de concepts entre projection (operateur géométrique) et contact | ||
+ | * Les structures de données stoquent des données redondantes (dans une même structure ou dans des structures voisines) | ||
+ | * On tente de faire faire à une même routine / classe des choses différentes | ||
+ | * le lagrangien augmenté ne fonctionne pas dès qu'il y a redémarrage d'un pas de temps (cf rapport de Stage Charles + visite de Philippe Bussetta) | ||
+ | * détection de faux contacts dans la douille gdTech via import du fichier step | ||
+ | * je me vois mal apte à ajouter des méthodes de contact différentes (contact surface / elements mortiers / éléments spéciaux à épaisseur de contact variables pour simuler l' | ||
+ | * ... | ||
+ | |||
+ | ===== Objectif ===== | ||
+ | * que l' | ||
+ | * que le projectionState ne contienne que les données relatives à une projection | ||
+ | * A discuter (Robo ?) que le projectionState soit une structure de classes (par exemple que le revolutionSurfaceProjectionState contienne un teta & un wireProjectionState) | ||
+ | * créer une structure de classes dérivées gérant les datas contact dans un objet type GpState (et que ce soit ce dernier qui contienne les différents projections states nécessaires à chaque material) | ||
+ | * couper decideContact en une classe 2D et une 3D et gérer ces aspects au niveau du contact et non de la projection | ||
+ | * any other idea (j' | ||
+ | | ||
+ | ===== Modifs ===== | ||
+ | |||
+ | * ** Unification de la triple définition de ksi ** | ||
+ | * Il existait dans le projectionState un | ||
+ | * double ksi | ||
+ | * double ksiS[2] | ||
+ | * double ksiL[2] | ||
+ | donnant 3 représentations de la projection en variables internes. Qui plus est, le code était plein de tests sur l' | ||
+ | * je n'ai laissé en place que un | ||
+ | * double ksi[2] | ||
+ | * J'ai viré toute référence à ksiL (je propose à celui qui veut tester la méthode, de le faire dans le matériau de contact au moment de calculer le frottement) | ||
+ | |||
+ | * ** Divers ** | ||
+ | * Ajout dans battery.py la recherche de editPadPro (à l' | ||
+ | |||
+ | ===== Futur Works - ToDo list ===== | ||
+ | * | ||
+ | ===== Tests ===== | ||
+ | * Ajout du test de douille dans oo_nda/ | ||
+ | |||
+ | ===== Projet ===== | ||
+ | * Up To Date | ||
+ | |||
+ | ===== Fichiers ajoutés/ | ||
+ | **Code** | ||
+ | < | ||
+ | A | ||
+ | R | ||
+ | </ | ||
+ | |||
+ | **Test** | ||
+ | < | ||
+ | A gdTech.tests.douille.douilleRd | ||
+ | A gdTech.tests.douille.douilleRdWoHole | ||
+ | </ | ||
+ | |||
+ | --- // |
commit/2008/09_24.txt · Last modified: 2016/03/30 15:23 by 127.0.0.1