Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2008:09_24

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'abrasion (newac))

Objectif

  • que l'opérateur de projection fasse une projection (rien de plus, rien de moins : l'ALE / les mailleurs n'ont besoin de rien d'autre que de la projection)
  • 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'attend vos suggestions)

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'utilisation de ksiL qui au final vu les restrictions n'était jamais utilisé (si sur des segments de droite en RD à condition de rester sur le même segment)

  • 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'emplacement par défaut) et si il existe, remplacement du notepad par editPadPro dans le fichier html …

Futur Works - ToDo list

Tests

  • Ajout du test de douille dans oo_nda/gdTech (geométrie python)

Projet

  • Up To Date

Fichiers ajoutés/supprimés

Code

A 
R 

Test

A gdTech.tests.douille.douilleRd
A gdTech.tests.douille.douilleRdWoHole 

Luc PAPELEUX 2008/09/24

commit/2008/09_24.txt · Last modified: 2016/03/30 15:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki