Metafor

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Commit - LPx - 31 Janvier 2018 =====

Parallélisation materiaux TM : utilisation de généralisée de GK.getK() et GK.getG() + Divers 

===== Parallélisation materiaux TM : travail sur les GKState =====

  * Pour paralléliser les matériaux thermomec, il est nécessaire d'utiliser les paramètres matériaux calculés à la température du point d'intégration. C'est le cas en série, pas encore en parallèle.
  * Comme étape préliminaire, j'ai regardé les appels aux variables G et K du matériau pour me rendre compte 
    * qu'il y en avait beaucoup
    * qu'il y en avait dans le calcul de la matrice de raideur tangente or on n'update pas les paramètres matériaux en fonction de la température avant le calcul de la matrice de raideur => toutes les matrices de raideurs thermomécanique étaient fausses !!!
    * on stoquait dans GK.GTilde soit le G élastique, le G élastoplastique (G*beta), le G endommagé (G*(1-damage)),... => j'ai remplacé GTilde par G dans tous les matériaux et recalculé les paramètres de raideur 
en fonction du matériau
    * idem au niveau de K
    * enfin, suite à ca, j'ai pu généraliser l'usage de GK.getG() et GK.getK() dans tous les calculs de raideur, mais aussi de chaleur générée (thermoélastique ou thermoplastique),...
  * Pour toujours pouvoir effectuer une analyse fréquentielle ou générer des super-éléments, l'initialisation des GKState a été ajoutée aux fonctions ''Material::initialise''
  * Les méthodes d'intégration des matériaux ont été adaptées à l'initialisation des GKStates

===== Matériaux composites =====
  * il y avait un bug de dérivation de ''OrthoHypoGpkState'' qui dérivait de ''CauchyMechanicalGpkState'' au lieu de ''HypoGpkState'', alors que dans une routine de calcul du matériau, il était casté en ''HypoGpkState'' => problèmes d'accès mémoire quand la matrice de rotation incrémentale était calculée
  * pour se conformer au naming en cours, le matériau ''OrthoElastHypoMaterial'' a été renommé ''ElastOrthoHypoMaterial'' (les tests ont été adaptés)
  * 

===== CMake - MetaforSetup : =====
  * Ajout des CMakeLists.txt dans oo_nda/fluotournage et oo_nda/hpc4we (installation)
  * Adaptation des fichiers oo_meta/CMakeLists.txt, oo_meta/CMake/disable-all-nda.cmake
  * Mise à jour de oo_meta/CMake/centos6.cmake (virtualBox centos6 pour générer la version Linux pour GDTech)
  * Adaptation de MetaforSetup pour les ndas fluotournage & hpc4we

===== Divers : =====
  * Correction d'un bug dans le calcul des boundingBoxes des ''CubicSpline'' et ajout de 2 tests de contact sur surface ''Coons'' supportées par des ''CubicSpline'' (apps/parallel)
  * suppression d'info de debug d'initialisation des threads (mtMath)
  * correction du test apps.biomec.longBone.boneRepairWithRod : la sélection des groupes entre os de gauche et de droite ne se faisait pas au bon endroit
  * interface Samcef : 
    * Ajout de la variable d'environnement ''SAM_USE_RLM=0'' option non supportée par samcef 17 (pour les cas où cohabiterait une version samcef 17 pour Metafor et samcef 18 pour NX).
    * La version samcef 18 ne nécessite pas cette option

===== Fichiers ajoutés/supprimés : =====
<code>
A : oo_nda/fluotournage/CMakeLists.txt
A : oo_nda/hpc4we/CMakeLists.txt
M : oo_meta\mtComposites\src\materials\OrthoElastHypoMaterial.h/cpp  => ElastOrthoHypoMaterial.h/cpp
</code>

===== Tests ajoutés/supprimés =====
<code>
Added : oo_meta/apps/parallel/contactCoonsSpline.py
Added : oo_meta/apps/parallel/contactCoonsSplinePress.py
Deleted : 
Moved : 
</code>

 --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2018/01/31 //