Herezh++

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.

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.

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) ?

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

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 ???

- 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

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.

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

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

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.

"ç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 !

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

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.

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.

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.

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_

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 ...

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.

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.

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

ok,
je vais réfléchir pour voir comment on pourrait plus facilement utiliser l'existant.

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).