Evolution #378
ouvertaccès DEF_EPAISSEUR en pondération de LOI_ADDITIVE_EN_SIGMA dans une LOI_CONTRAINTES_PLANES
Ajouté par Julien Troufflard il y a 4 mois. Mis à jour il y a 4 mois.
Description
Gérard,
je lance cette discussion concernant l'accès à la grandeur DEF_EPAISSEUR pour faire une pondération de loi additive au sein d'une loi contrainte plane.
Je veux faire une pondération de loi qui dépend d'une fonction nD (pour calculer def mises au sens log et en tenant compte de la composante 33) et que cette fonction nD puisse utiliser DEF_EPAISSEUR.
en pièce jointe => un exemple en traction sur un quadrangle
Il y a deux choses à résoudre :
1) pouvoir utiliser une fonction nD
2) accéder à DEF_EPAISSEUR
voici pour le 1) :
pour pondérer, on utilise avec_fonction_de_ponderation_. Et pour utiliser une fonction nD, j'ai l'impression qu'il faut faire une manip un peu bizarre. Je déclare d'abord une pondération fictive sur courbe 1D et def_duale_mises qui ne fait rien (ponderation = 1) puis une seconde pondération normalement dédiée aux grandeurs locales (avec_ponder_grandeur_locale_). C'est la seule manière que j'ai trouvé pour utiliser une fonction nD sans que ça génère de bug.
ça donne la tournure :
MAT LOI_CONTRAINTES_PLANES
... param loi contrainte plane ...
LOI_ADDITIVE_EN_SIGMA
avec_fonction_de_ponderation_
#ponderation courbe 1D sans impact (toujours egale a 1)
les_grandeur_ponderation= def_duale_mises AuPti_ fin_grandeur_ponderation_
deb_fonct_ponder= COURBEPOLYNOMIALE
debut_coef= 1. fin_coef
fin_fonct_ponder_
#ponderation locale qui permet acces a une fonction nD
# (aucune grandeur ne lui est passee)
avec_ponder_grandeur_locale_
les_grandeurs_= fin_grandeurs_
deb_fonct_= fct_ma_fonction fin_fonct_
#une loi 3D qui va etre ponderee
... loi 3D ...
fin_liste_lois_elementaires
fin_loi_contrainte_plane
ensuite, la fonction nD aura cette allure :
fct_ma_fonction FONCTION_EXPRESSION_LITTERALE_nD deb_list_var_ EPS11 EPS22 EPS12 DEF_EPAISSEUR fin_list_var_ fct= ... un calcul ... permet_affichage_ 6 fin_parametres_fonction_expression_litterale_
donc c'est elle qui s'occupe d'appeler les bonnes grandeurs.
ça fonctionne comme mécanisme, mais c'est un moyen détourné. Normalement "avec_ponder_grandeur_locale_" est sensé servir à autre chose non ?
et ensuite le point 2) => l'accès à DEF_EPAISSEUR
pour l'instant, l'exemple pièce jointe ne fonctionne pas à cause de DEF_EPAISSEUR qui n'est pas accessible. J'ai essayé de regarder les fichiers source .h et .cc de HYPO_ELAS2D_C pour laquelle l'accès à DEF_EPAISSEUR avait été résolu.
J'ai relevé quelques "void" de hypoelas (Hypo_hooke2D_C.cc) qui mentionnent DEF_EPAISSEUR et qui n'existent pas dans loi contrainte plane (LoiContraintesPlanes.cc) :
- ::Mise_a_jour_map_type_quelconque
- ::Insertion_conteneur_dans_save_result
- ::Activation_stockage_grandeurs_quelconques
finalement, les seuls en commun entre les 2 lois de comp sont :
- ::Grandeur_particuliere
- ::ListeGrandeurs_particulieres
qu'est-ce qui fait que HYPO_ELAS2D_C transmet DEF_EPAISSEUR aux fonctions nD (via le saveResult ?) et pas LOI_CONTRAINTES_PLANES ?
Fichiers
| calcul.CVisu (12,4 ko) calcul.CVisu | Julien Troufflard, 08/11/2024 19:21 | ||
| calcul.info (1,94 ko) calcul.info | Julien Troufflard, 08/11/2024 19:28 |
Mis à jour par Gérard Rio il y a 4 mois
- Tracker changé de Anomalie à Evolution
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 10
qq infos:
- DEF_EPAISSEUR est une grandeur spécifique aux lois en contraintes planes. Elle est a priori accessible en post-traitement.
- pour les lois additives en sigma, les pondérations sont calculées par la méthode:
LoiAdditiveEnSigma::CalculGrandeurTravail(...
- dans cette méthode on récupère la liste des grandeurs nécessaires à la fct nD et on interroge les lois individuelles pour récupérer les grandeurs locales correspondantes aux grandeurs nécessaire. Auparavant, au moment de la lecture la loi additive vérifie que les grandeurs nécessaires sont bien disponibles au niveau des lois incluses, ceci via la méthode:
LoiAdditiveEnSigma::Verif_et_preparation_acces_grandeurs_locale()
cette méthode interroge chaque loi interne via la méthode générique (existante pour toutes les lois):
Existe_stockage_grandeurs_quelconques(..
qui se trouve dans Loi_comp_abstraite . Cette méthode vérifie dans la liste "listdeTouslesQuelc_dispo_localement" que la grandeur demandée existe, il faut donc que cette liste ait été abondée pendant la construction de la loi individuelle. Cela ce fait pour chaque loi via la méthode de Loi_comp_abstraite:
// insertion des conteneurs ad hoc concernant le stockage de grandeurs quelconques
// passée en paramètre, dans le save result: ces conteneurs doivent être valides
// c-a-d faire partie de listdeTouslesQuelc_dispo_localement
virtual void Insertion_conteneur_dans_save_result(SaveResul * saveResul) {} ;
Par défaut cette méthode ne fait rien, ce qui permet à chaque loi de se construire sans pb. Mais si on veut rajouter des infos, on redéfinie cette méthode dans la loi (car elle est initialement définie en "virtual").
exemple que tu as effectivement relevé : dans Hypo_hooke2D_C.cc, elle est redéfinie.
Si on regarde dans la loi contrainte plane, elle n'existe pas. Donc il faut en définir une (par exemple sur le modèle de Hypo_hooke2D_C, mais il y a d'autre loi avec une définition, donc c'est instructive d'en regarder quelques une).
Il faut aussi définir les deux méthodes qui sont associées: Activation_stockage_grandeurs_quelconques et Mise_a_jour_map_type_quelconque
qui permettent de définir une map pour un accès direct.
- Toutes les grandeurs accessibles en post-traitement peuvent être mise en accès via la méthode présentée.
- c'est une méthodologie que j'ai mise en place pour pouvoir compléter à la demande (des utilisateurs) les méthodes qui compte tenu de leur évolution, en ont besoin: typiquement ta demande.
Je te propose de faire les ajouts en mettant à jour les sources via git.
Je suis à ta disposition si tu as des interrogations et des pb.
Mis à jour par Julien Troufflard il y a 4 mois
ok je vais regarder pour la partie DEF_EPAISSEUR.
et qu'en est-il concernant l'activation d'une fonction nD pour la pondération (le point 1) de mon ticket) ?
Dans les lois de melange, l'accès aux fonctions nD est direct. Faudrait peut-être que je regarde son .h/.cc pour comprendre.
Mais je vais commencer par la partie DEF_EPAISSEUR avant de regarder ça.
Mis à jour par Gérard Rio il y a 4 mois
Oui, je pense que le point 1 n'est pas bloquant (à regarder au niveau de la lecture: et comparer avec le cas de la loi des mélanges sachant qu'il y a de fortes ressemblances, mais ce n'est pas exactement la même méthodo si je me rappelle bien ...) en tout cas je pense que tu peux laisser ce point en attente. Le plus intéressant c'est l'intro de l'accès à une grandeur gérée par une loi interne: normalement je pense que ce ne sera pas compliqué, mais ça te permettra de regarder le fct interne et ensuite de pouvoir y adjoindre de nouvelle grandeur en fct de ce qui t'intéresse.
Mis à jour par Julien Troufflard il y a 4 mois
un point à éclaircir sur les sources herezh :
sur github, la dernière version dispo est la branche v_7.034 tandis que la dernière version exécutable sur le site d'herezh est v7.037.
Pour l'instant, je vais commencer à travailler depuis v_7.034.
Mais pourquoi ce décalage entre version HZpp et version des sources ? A quoi sert la branche Master (vieille de 3 ans) ?
Mis à jour par Julien Troufflard il y a 4 mois
la compilation renvoie 5 erreurs avec la v_7.034
ça vient de AlgoriMixte.cc, il y a 5 appels du type :
lesMail->Vect_glob_vers_local(TEMPS_tdt,GAMMA1,acceleration_tdt,GAMMA1);
4 arguments sont passés à Vect_glob_vers_local(), et il en faudrait 5 d'après le fichier LesMaillages.cc
je suis repassé sur la branche v_7.030
Mis à jour par Julien Troufflard il y a 4 mois
rien à voir mais dans le v_7.030, j'ai peut-être repéré une erreur dans loi hypo2D_C.cc. Je préfère la signaler dès maintenant avant d'oublier. désolé pour le hors-sujet.
je vois qu'il y a écrit ligne 1247 :
void Hypo_hooke2D_C::Verif_et_preparation_acces_grandeurs_locale()
{list <EnumTypeQuelconque > listEnuQuelc; // def de la liste des grandeurs quelconque
// ---récup des grandeurs quelconques nécessaires pour les fonction nD
if (mu_nD != NULL)
{const Tableau <EnumTypeQuelconque>& tab_enu_quelc = mu_nD->Tab_enu_quelconque();
int tail = tab_enu_quelc.Taille();
if (tail)
{for (int i = 1; i<= tail; i++)
listEnuQuelc.push_back(tab_enu_quelc(i));
};
};
if (Kc_nD != NULL)
{const Tableau <EnumTypeQuelconque>& tab_enu_quelc = mu_nD->Tab_enu_quelconque();
int tail = tab_enu_quelc.Taille();
if (tail)
{for (int i = 1; i<= tail; i++)
listEnuQuelc.push_back(tab_enu_quelc(i));
};
};
etc...
dans le "if(Kc_nD != NULL)", il y a ensuite :
const Tableau <EnumTypeQuelconque>& tab_enu_quelc = mu_nD->Tab_enu_quelconque();
c'est pas plutot Kc_nD->Tab_enu_quelconque(); qu'il fallait mettre ???
Mis à jour par Gérard Rio il y a 4 mois
- ah oui !! c'est exact il faut Kc_nD, c'est modifié ! merci
- concernant AlgoriMixte, il faut désactiver cette classe (ne pas l'utiliser). C'est un algo que j'avais commencé à concevoir, mais qui au final fait double emploi avec l'existant. Il se trouve qu'il est resté dans les sources, mais il ne sert plus actuellement.
- dans tous les cas la version 7.034 doit fonctionner (elle fonctionne chez moi), donc il vaut mieux utiliser la dernière version
- effectivement j'aurais pu mettre tout dans la version master et simplement taguer les évolutions. Mais j'ai pris une autre technique, je fais une version pour chaque évolution ce qui permettrait éventuellement de travailler sur cette version spécifiquement... Bon je ne suis pas un spécialiste de git donc il est possible que ce ne soit pas la bonne solution, mais j'ai l'impression que par exemple boost utilise cette technique ... en tout cas, ce n'est pas un pb a priori
Mis à jour par Julien Troufflard il y a 4 mois
Vu pour algoriMixte
Pour KcnD, ce qui est bizarre c'est que j'ai fait des lois qui calculent Kc avec une fct nD et elles fonctionnaient comme prévu. Il va falloir que je regarde ça quand tu auras remis à jour une version Hzppfast.
Mis à jour par Julien Troufflard il y a 4 mois
Concernant loi contrainte plane et def epaisseur
J'ai tenté de faire un copier coller de ce qu'il y a dans loi hypo 2D_C vers loi cp .h et .cc. j'ai réussi à compiler mais ça n'a pas permis de rendre def epaisseur accessible (toujours la même erreur)
J'en viens à me demander si j'ai bien compris le fonctionnement des infos passées entre des lois imbriquées.
Exemple : supposons une loi dans le .info de la forme :
Loi 1
Loi 2
Loi 3
Fin loi 3
Fin loi 2
Fin loi 3
Comment se passe le passage d'infos. Est-ce que toutes les lois se passent leurs infos entre elles ?
Où est-ce c'est ascendant, au sens où une sous-loi transmet à sa loi "parent" (loi 3 transmet à loi 2 qui transmet à loi 1)
Si c'est ascendant uniquement, alors je suis marron utiliser def_epaisseur dans une ponderation de loi additive.
Car dans mon exemple joint à ce ticket, j'ai :
Loi 1 = loi cp
Loi 2 = loi 3D additive avec ponder
Loi 3 = loi 3D additive
La loi 3 est 3D mais transmet un EPS33 nul à la loi 2, donc je ne peux pas non plus utiliser eps33
Mis à jour par Gérard Rio il y a 4 mois
Je modifie un peu ton exemple: supposons:
Loi 1
Loi 2
Loi 3
Fin loi 3
Loi 4
Fin Loi 4
Fin loi 2
Fin loi 3
la méthodologie que j'ai implantée fonctionne de la manière suivante:
- la loi 2 peut récupérer les infos de la loi 3 et la loi 4 et les mets au service de ces 2 lois. Donc finalement la loi 3 peut utiliser les infos de la loi 4 (de l'itération précédente)
- dans tous les cas, la loi 2 peut utiliser les infos des lois internes donc des lois 3 et 4. Donc la loi 1 peut utiliser les infos de la loi 2 qui agglomère celles des lois 3 et 4
- théoriquement on a des infos qui circulent dans les deux sens. Mais à voir en pratique, car je n'ai pas vraiment fait de test à ce niveau. J'ai conçu ce mécanisme pour la thèse d'Émilie avec comme objectif de l'utilisation des infos de la loi 3 par la loi 4 et la loi 2. Avec l'idée de mettre des choses qui peuvent ensuite être complétées à la demande.
- Si on veut que la loi additive (loi 2) utilise les infos de la loi 1, ça ne peut-être que les infos de l'itération précédente (celle qui a permis de calculer la loi 2 avec la condition de contrainte plane). En fait dans un processus itératif, on peut craindre de ne jamais converger (ou alors par chance). Une solution que je vois c'est de pouvoir utiliser les infos de l'incrément précédent.
Il y aura un décalage, mais au moins ce sera stable dans un processus itératif. Ensuite il faudra voir l'impact du décalage ...
Dans ce cas il faut pouvoir dire qu'il s'agit du def epaisseur de l'incrément précédant du genre DEF_EPAISSEUR_T (si on suit la logique de l'écriture des variables que j'utilise dans Herezh)
bon... à voir à l'utilisation
Ceci étant en marge de cette réflexion (et en //) , tu peux peut-être en profiter pour tester une méthode de mise à jour:
- charger sur le site git de l'ubs, tes fichiers modifiés dans une branche de travail
- je charge tes fichiers pour regarder
Mis à jour par Julien Troufflard il y a 4 mois
ok pour git, je vais regarder comment faire
pour le reste :
ça m'embête un peu de passer par une donnée à l'itération/incrément précédent (même si ça pourrait être un dernier recours).
Je voudrais comprendre pourquoi une loi 3D ne peut remonter sa composante EPS33.
Je reprends mon exemple à 3 lois, en corrigeant le dernier "fin loi" (j'avais mis 3 au lieu de 1) et en ajoutant le type de loi et ce qui est à mon sens sa dimension (2D ou 3D) :
Loi 1 (contrainte plane => "2D")
Loi 2 (additive avec ponderation => "3D")
Loi 3 (peu importe le type mais néanmoins "3D")
Fin loi 3
Fin loi 2
Fin loi 1
On est sur un élément membrane, donc un tenseur dans le plan EPS11, EPS22, EPS12.
Mais on passe par des lois 3D, qui elles ont forcément une composante 33. Par exemple, on peut imaginer que la loi 3 est simplement une loi ISOELAS (donc 3D).
Questions :
- il va y avoir un calcul de la contrainte pour la loi 3 => est-ce qu'il est fait en utilisant un tenseur de déformation 3D ?
- et si oui, pourquoi est-ce que la loi 3 ne remonte pas sa composante 33 à la loi 2 ? (à la place, elle envoie 0 sans erreur, c'est-à-dire que le ddl existe, mais il n'y a rien dedans)
- et par extension, si la loi additive ne remonte rien en 33 pour l'instant => est-ce qu'il y a moyen de faire en sorte qu'il y ait cette remontée ? Et ceci peut être envisagé de 2 manières :
1) on crée un cas spécial disant que dans un contexte général 2D (contexte donné par la loi 1), toutes les lois 3D contenues dans la loi CP doivent remonter une composante 33 au sens de EPS33
2) au contraire => pas de cas spécial. Pour une loi 3D classique, EPS33 est remontée naturellement, et bien il faudrait faire en sorte que peu importe le contexte => une loi 3D doit remonter son EPS33 non nul.
Mis à jour par Gérard Rio il y a 4 mois
"ça m'embête un peu de passer par une donnée à l'itération/incrément précédent (même si ça pourrait être un dernier recours)."
c'était une remarque de ma part, l'utilisation de la grandeur à l'itération précédente est plus immédiate, donc ok
"Je voudrais comprendre pourquoi une loi 3D ne peut remonter sa composante EPS33."
je pense savoir pourquoi il y a ce pb, qui est d'ailleurs un pb plus général à savoir: comment faire lorsque l'on veut utiliser une grandeur qui est présente dans plusieurs lois associées.
Si jamais tu avais voulu utiliser une grandeur qui existait uniquement dans une des lois, là je pense qu'il n'y aurait pas de pb (au moins théoriquement, mais à voir au niveau réel de fct)
Par contre concernant les grandeurs types déformations ... ce n'est pas si simple, car les def existent pour toutes les lois et dans herezh, on peut (théoriquement) utiliser une mesure de def différente pour chaque loi. Du coup, par défaut on va d'abord regarder ce qui est directement dispo dans la loi qui en a besoin, et éventuellement si on ne trouve pas l'info, on regarde ailleurs.
Dans l'exemple:
on veut EPS33: au niveau de la fct nD on détecte qu'il s'agit d'une composante de tenseur, du coup de manière systématique on va récupérer l'objet tenseur . Donc on récupère l'objet tenseur directement associé via la méthode générique :
Loi_comp_abstraite::Valeurs_Tensorielles_interpoler_ou_calculer
Dans cette méthode comme il s'agit des def, on cherche directement à utiliser les grandeurs stockées aux pti. On détecte au pti qu'il s'agit de tenseur 2D, on récupère le tenseur. Ensuite comme il s'agit de grandeur utilisée par une fct nD, on transforme systématiquement ces grandeurs dans le repère ortho global ce qui donne une valeur de eps33 = 0
Donc si on veut abonder ce mécanisme pour répondre à ta demande, il faut par exemple pouvoir spécifier dans le .info quelle variable associée à quelle loi.
Ça pourrait être accolé à la grandeur voulue une chaine de caractères qui contiendrait le nom de la loi par exemple, et donc pourrait ensuite être diversifié autrepart.... mais il faut aussi définir un mécanisme pour récupérer l'info...et ceci de manière efficace.
Une autre solution plus rapide à l'exécution (a priori) mais moins facile à utiliser serait d'utiliser la même technique que pour la sortie d'info. Lorsqu'une grandeur est présente dans plusieurs lois combinées on utilise un stockage en tableau avec un indiçage qui correspond à la position de la loi dans l'arbre de def de la loi combinée. Donc on pourrait utiliser cette position pour identifier la grandeur...
à creuser !
Mis à jour par Julien Troufflard il y a 4 mois
et il n'y aurait pas moyen de généraliser le concept de DEF_ASSO_LOI de hypo_elas ?
ça deviendrait une grandeur particulière même si en fait c'est tout simplement EPS dans le cas ISOELAS
Mis à jour par Julien Troufflard il y a 4 mois
ou peut-être il vaut mieux créer une nouvelle grandeur pour être sûr que ce soit EPS quelque soit la loi.
par exemple "EPS_LOI" qui permet d'utiliser le EPS almansi de la loi.
c'est surtout pour être sûr que ce soit toujours EPS almansi, quelque soit la loi. Parce que dans le cas de DEF_ASSO_LOI, ça change selon le transport.
Mis à jour par Julien Troufflard il y a 4 mois
edit :
j'ai dit :"pour être sûr d'utiliser le EPS almansi de la loi"
mais non, en vrai, pour être raccord avec le fonctionnement Herezh, ce serait le EPS selon le "type_de_deformation" choisi pour la loi.
Mis à jour par Gérard Rio il y a 4 mois
Je ne suis pas sûr de bien comprendre:
quel que soit la grandeur que tu choisis le pb arrive lorsqu'il y a multiplicité de la grandeur. Si on définit EPS_LOI, a priori elle peut exister pour toutes les lois donc laquelle on choisit dans le cas d'une loi combinée.
Mis à jour par Julien Troufflard il y a 4 mois
et bien je ne sais pas trop non plus.
Donc si on repart de l'exemple des 3 lois :
Loi 1 (contrainte plane => "2D")
Loi 2 (additive avec ponderation => "3D")
Loi 3 (peu importe le type mais néanmoins "3D")
Fin loi 3
Fin loi 2
Fin loi 1
en l'occurrence, c'est "loi 2" qui veut faire une pondération. Donc je suppose que ce serait le EPS_LOI de "loi 2" qui doit être utilisé pour faire la pondération.
A l'origine, je voulais utiliser dans "loi 2" une grandeur venant de "loi 1" (DEF_EPAISSEUR). Donc, il y avait un problème de transmission de grandeur entre lois (d'où ma question ascendant versus pas ascendant).
Mais si "loi 2" possèdait déjà sa propre grandeur EPS_LOI, alors mon problème ne devient plus un problème de transmission. ça devient un problème classique. Qui suppose juste de créer EPS_LOI et de la rendre disponible aux fonctions nD.
Et supposons maintenant que cette grandeur soit créée, il y aurait un certain nombre de composantes dedans. Comment ce serait rangé ? Comment on accède à ses composantes dans une fonction nD ?
est-ce que ce serait un truc du genre ça :
fct_ma_fonction FONCTION_EXPRESSION_LITTERALE_nD deb_list_var_ EPS_LOI fin_list_var_ fct= EPS_LOI[1]^2 + EPS_LOI[2]^2 + EPS_LOI[3]^2 + etc... fin_parametres_fonction_expression_litterale_
Mis à jour par Gérard Rio il y a 4 mois
ok,
mais on voit que c'est globalement assez complexe, car cela va impacter pas mal d'endroits. Du coup, je propose d'y aller petit à petit.
Premier point effectivement introduire une grandeur particulière.
Au niveau de la contrainte, j'ai déjà introduit une grandeur de ce type, il s'agit de:
CONTRAINTE_INDIVIDUELLE_A_CHAQUE_LOI_A_T
là on voit qu'il s'agit de la grandeur à t c-a-d à l'incrément précédent donc pour nous ici il faudrait (en suivant quelque chose qui est ressemblant):
DEF_INDIVIDUELLE_A_CHAQUE_LOI
et tant qu'on y ait, on prévoit le cas où on voudrait utiliser la chose à t
DEF_INDIVIDUELLE_A_CHAQUE_LOI_A_T
Du coup, il faut introduire ces deux grandeurs dans la liste d'énumération, au niveau des deux fichiers:
Enum_TypeQuelconque.h et Enum_TypeQuelconque.cc
Dans ce dernier fichier il faut également mettre à jour le nombre de grandeurs:
cf. par exemple sur ma version:
ligne 294: tt_GLOB.Change_taille(224);
ligne 521: tt_TQ_temps.Change_taille(224);
(au cas ou: Pour faire les changements, le plus simple dans un éditeur est de repérer la grandeur CONTRAINTE_INDIVIDUELLE_A_CHAQUE_LOI_A_T dans le fichier .cc et de recopier 2 fois la ligne et ensuite de faire les changements ad hoc après s'être positionné sur chaque nouvelle ligne)
Pour l'instant je m'arrête là pour ne pas embrouiller le reste, mais juste qq remarques:
- il va falloir intervenir a priori dans toutes les lois ... ce ne sera pas très compliqué, car une fois la méthodologie trouvée on aura en gros la même technique à utiliser. Mais il y a un peu de travail.
- ce serait bien d'utiliser une stratégie pour éviter de stocker inutilement ces infos dans le cas où on ne les utilise pas. J'ai déjà mis en place ce genre de chose, mais cela nécessite d'introduire du code pour gérer.
- ensuite viens l'accès, là aussi il y aura des choses à faire ...
- bref, bien voir que l'ensemble n'est pas indolore (j'en sais quelque chose pour l'avoir moult fois fait) mais c'est intéressant.
à suivre ...
Mis à jour par Julien Troufflard il y a 4 mois
Ok.
Juste une remarque. Pourquoi reprendre cette appellation "individuelle a chaque loi". Pour la contrainte oui. Mais dans le cas de la deformation, elle est identique dans toutes les lois dans un modele rhéologique en parallèle.
Mis à jour par Gérard Rio il y a 4 mois
oui et non:
l'appel principal provient de la class Loi_comp_abstraite via par exemple:
Loi_comp_abstraite::Cal_implicit
et dans cette méthode effectivement on détermine un type de def, qui est ensuite transmise aux lois. Donc on peut dire que la def est identique pour toutes les lois mais ...
supposons que l'on utilise une loi incrémentale du type hystérésis ou hypo. Dans ce cas la loi interne n'utilise pas la def de base, mais une construction propre qui est en générale paramétrée spécifiquement: ex: transport covariant ou contra, ou mixte (Jauman). Du coup on abouti à une def interne qui est sauvegardé dans la loi particulière et on peut dire que la loi a une def spécifique. Donc si on a un assemblage de plusieurs lois, on peut avoir différents types de def qui cohabitent.
Mis à jour par Julien Troufflard il y a 4 mois
pour les types de déf, justement je voudrais éviter que chaque loi envoie sa déf de travail (avoir EPS tout le temps et rien que EPS).
Mais avant de se lancer dans les travaux, j'ai re-réfléchi à mon besoin. Il faut quand même énoncer la finalité de tout ça. Je veux :
1) calculer la déformation mises et le cos(3phi)
2) le faire pour la mesure de déf log (en passant par les valeurs propres de EPS, puis conversion en log)
3) tenir compte de la composante 33 dans ces calculs d invariants (ce que ne fait pas def_duale_mises et cos3phi_eps)
donc à partir de là, est-ce qu'il n'y a pas un moyen plus simple pour accéder à ces 2 grandeurs type log.
Je me pose par exemple la question du stockage et de l'efficacité. Ne vaut-il pas mieux :
- fournir directement ces 2 grandeurs (2 petits scalaires qui ont la bonté d'être indépendants du repère)
- plutôt que de devoir stocker le tenseur EPS (6 composantes) et devoir faire appel à des fonctions nD
Mis à jour par Gérard Rio il y a 4 mois
ok,
je vais réfléchir pour voir comment on pourrait plus facilement utiliser l'existant.
Mis à jour par Julien Troufflard il y a 4 mois
ok.
pour être complet, il faut aussi le premier invariant (trace).
ce qui permettra si besoin de remonter à la norme du tenseur total via la trace et la def mises (j'ai besoin la norme de eps log dans des lois hypoélastiques).