HPC4WE : parallelisation materiaux TM :

On y arrive enfin …

• L'idée initiale de paralléliation des matériaux TM était
  1. de générer un objet PRMat par matériau
  2. de dupliquer cet objet au besoin (via un getClone) et d'adapter la copie à la température du point d'intégration
• Or la gestion mémoire de cette approche n'a pas fonctionné :
  • Le getClone posait problème avec la structure Diamant des PRMat Ther et TM (⇒ j'ai remplacé la dérivation par de la composition. Mais là, c'est le thixo qui posait problème dans la reconstruction de la matrice de capacité thermique qui dépend de la fraction liquide, … ⇒ la partie thermique dépend de la partie méca)
  • j'ai du implémenter des fonctions d'allocation pour chaque PRMat et PRMLaw : virtual PRMat *allocPRMat(); ainsi que dans chaque famille de MaterialLaw (pour garder un certain typage) : virtual YieldStressPRMLaw* allocYieldPRMLaw(); (on pourra revenir là dessus si ce n'est pas nécessaire)
  • J'avais prévu de gérer la gestion mémoire des PRMat et Matériaux par RefCounted or
    • RefCounted n'est pas threadSafe (et je me retrouvais à supprimer le matériaux sous-jascent au PRMat en plein milieu d'une intégration) et mettre un mutex était hors de propos
    • le debug “en dur” des RefCounted sur un objet “pureVirtual” n'est pas possible
• Au final, j'ai appliqué la deuxième approche envisagée avec Romain qui est de définir une map de PRMat allouée sur chaque thread (en profitant des objets “ThreadLocalStorage” de TBB)
  • les threads pouvant être éteint et rallumé en cours de calcul (je ne crois pas que ca arrive dans Metafor, mais il faut prévoir le coup), les objets doivent pouvoir être alloués et initialisés à tout moment du calcul. Celà passe par la fonction getPRMat. Attention, commme celle ci alloue un prmat, elle n'est pas const (et j'ai donc du enlever des “const” en cascade dans des fonctions en aval d'appel à getPRMat)

PRMat *
MechanicalMaterial::getPRMat()
{
    PRMat *pmat = tlsPrmats.local();
    if (pmat == NULL)
    {
        tlsPrmats.local() = allocPRMat();
        pmat = tlsPrmats.local();
        pmat->init();
        pmat->update();
    }
    return pmat;
}

• Les copyConstructors des PRMat (PRMLaw) ont été supprimés et les classes déclarées en “DISABLE_COPY”
• Les tests de validité de présence des paramètres matériaux ont été remis en place dans la fonction CheckPRMat “XXXMaterial::checkPrmat()” pour que la vérification soit faite en amont de l'allocation de la structure PRMat (prépro)
• Les fonctions PRMat::init() ont été complétées (getConstant)
• Il faudrait ajouter des bool pour chaque paramètre pour savoir si dépendance il y a (pour limiter le nombre d'updates ⇒ optimisation future)
• Pour la gestion du Thermique/ThermoMec : j'ai ajouté de manière temporaire des fonctions updateTher et updateTM (encore une fois pour gérer le Thixo, je suis obligé de passer par le PRMat “générique”)

• le fait d'inclure “#include <tbb/enumerable_thread_specific.h>” dans un fichier .h pose des petits problèmes à travers “#include “machine/windows_api.h””
  • max est redéfini (⇒ std::max n'est plus compilable) ⇒

#include <tbb/enumerable_thread_specific.h>
#if defined(max)
#undef max
#endif

• Unknown est un nom défini dans une énum de windows ⇒ j'ai ajouté un namespace “mtf::” sur la classe Unknown
• ce namespace a été propagé dans tout le code (ALE et DataTransfert)

• En debuguant des tests TM, je me suis rendu compte que les éléments de conditions limites thermiques (convection, flux, rayonnement) n'avait pas de matrice de raideur analytiques
• Or il est impossible de faire du parallèle avec des matrices de raideur numériques (modifications de la DB)
• ⇒ j'ai implémenté les matrices de raideurs analytiques Thermiques de ces éléments (⇒ utilisables uniquement en schéma étagé. En schéma “fullCouplé”, il faudra calculer les matrices de raideurs analytiques complètes TM (pas fait, mais elles n'existent pas pour les éléments de volume non plus)
• ⇒ j'ai du imposer les matrices numériques sur les tests full et ajouté un FATAL_ERROR pour empécher l'utilisateur de faire du fullcouplé analytique

* J'ai aussi enlevé les “static std::vector<…>” dans le calcul des forces externes thremiques des mêmes éléments de CL thermiques

Added : 
Deleted : 
Moved : 

Adding: oo_meta\apps\parallel\thermoEvpIsoHTrac.py 
Adding: oo_meta\apps\parallel\thermoEvpIsoHRot.py 
Adding: oo_meta\apps\parallel\thermoEvpIsoH.py  
Adding: oo_meta\apps\parallel\thermoElastRot.py  
Adding: oo_meta\apps\parallel\thermoElast.py  
Adding: oo_meta\apps\parallel\striction3DTmAle.py  
Adding: oo_meta\apps\parallel\striction3DTm.py  
Adding: oo_meta\apps\iso\thermoEvpIsoHTrac.py  
Adding: oo_meta\apps\iso\thermoEvpIsoHRot.py  
Deleted : 
Moved : 

— Luc Papeleux 2018/11/20