Tutoriel Code_Aster

Posté par  . Édité par Davy Defaud, ZeroHeure, bubar🦥, Benoît Sibaud et palm123. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
47
7
jan.
2018
Science

Une fois n’est pas coutume, il pleut en Haute‐Garonne ! Alors j’ai tué le temps jetant un œil à Code_Aster, qui est un code de calcul de structure thermomécanique par la méthode des éléments finis isoparamétriques. Il est développé par EDF sous licence GNU GPL v3. Il permet de faire à peu près tout ce qui est imaginable en mécanique, voir à ce propos la plaquette de présentation (PDF).

logo code_aster

Ce code de calcul est intégré à la suite de logiciels libres Salomé‐Méca, qui contient un préprocesseur, Code_Aster, et un post‐processeur/visionneur pour voir les résultats. Aujourd’hui, nous allons utiliser le code en version autonome (stand alone) et nous utiliserons notre éditeur de texte préféré, gmsh, astk, puis de nouveau gmsh pour voir les résultats de nos calculs.

Sommaire

Installation

Cela se passe ici. Deux options :

  1. soit on compile code_aster ;
  2. soit on n’aime pas compiler et l’on télécharge le binaire de Salomé‐Méca qui contient Code_Aster de façon préinstallé et quelques Gio d’outils dont nous ne nous servirons pas.

La compilation se passe assez bien, et les paquets prérequis (voir les instructions de compilation sur leur site) se trouvent assez facilement.

Calcul de poutre

Nous allons étudier le comportement mécanique d’une poutre encastrée d’un côté et soumise à un effort ponctuel de l’autre côté :
Poutre encastrée

Nous allons le faire de trois façons :

  1. En modélisation poutre 1D ;
  2. En modélisation plaque 2D ;
  3. En modélisation complète 3D.

Création de la géométrie avec Gmsh

Pour fonctionner, Code_Aster a besoin d’un fichier de commandes, et d’un fichier décrivant un maillage : une liste de nœuds et une liste d’éléments reliant ces nœuds. On pourrait lui fournir un fichier texte contenant les coordonnées géométriques de chaque nœud du maillage, mais vu qu’on a la flemme et que cela peut être assez ennuyeux pour des problèmes complexes, on va demander à Gmsh de le faire pour nous.

On crée tout d’abord la géométrie de notre problème à l’aide de points, de lignes, surfaces et volumes, on doit aussi définir des groupes d’intérêts (la poutre entière, la partie encastrée et la partie sur laquelle on applique la force). On peut jouer cinq minutes avec la partie interface graphique de Gmsh, pour lequel on trouvera de nombreux tutoriaux sur le Web, mais on en revient vite à un fichier texte.

Voici donc poutre1d.geo :

//== paramètres ==
//taille maillage autour des nœuds. 2,5mm entre deux nœuds.
cl__1 = 2.5;

// == géométrie ==
//points
Point(1) = {0,0, 0, cl__1}; // extrémité encastre de ma poutre
Point(2) = {100,0, 0, cl__1}; // extrémité libre de ma poutre, soumise à une force
//lignes
Line(1) = {1, 2}; // on crée la ligne entre Point1 et Point2

//== groupe ==
Physical Point("encastr") = {1};
// on encastrera le nœud correspondant à ce point

Physical Point("force") = {2};
//on appliquera la force sur le nœud correspondant à ce point

Physical Line ("poutre") = {1};
// notre poutre sera constituée de tous les nœuds et éléments correspondant à cette ligne

Une fois ce fichier poutre1d.geo créé, on l’ouvre avec gmsh (terminal : gmsh poutre1d.geo). On clique sur Mesh1D, le maillage est fait, mais on ne le voit pas, car seule la géométrie est affichée ! Donc, ToolsOptions, onglet Visibily de Geometry, on décoche Points et Lines, et dans Mesh, on coche Nodes et Lines. Cela donne ceci :
Maillage 1D

Notez qu’avec ToolsOptions, dans l’onglet list bowser, on peut visualiser ou masquer (taper la touche Entrée au clavier après avoir cliqué sur le nom du groupe dans la fenêtre) les groupes que nous avons créés et leurs affectations. C’est très pratique. On voit par exemple bien que notre groupe « poutre » est constitué de tous les éléments de la poutre.

Pour sauvegarder notre maillage, on fait FileExport et l’on choisit le format de maillage appelé .MED, on obtient donc un beau mesh1d.med. Surtout, on veille à ce que tout soit décoché dans la fenêtre surgissante qui apparaît et l’on clique rapidement sur OK.

De même, voici poutre2d.geo, qu'on maille en 2D avec gmsh:

//== paramètres: ==
//taille maillage autour des nœuds. 2,5mm entre deux nœuds.
cl__1 = 2.5;
L=100; //longueur poutre de 100mm
R=5; // ratio longueur/largeur
l=L/R;

//== géométrie ==
//points
Point(1) = {0, 0, 0, cl__1};
Point(2) = {L, 0, 0, cl__1};
Point(3) = {L, l, 0, cl__1};
Point(4) = {0, l, 0, cl__1};
Point(5) = {L, l/2, 0, cl__1};
//lignes
Line(1) = {1, 2};
Line(2) = {2, 5};
Line(3) = {5, 3};
Line(4) = {3, 4};
Line(5) = {4, 1};

//surface
Line Loop(1) = {1, 2, 3, 4, 5}; //on crée une boucle de lignes
Plane Surface(1) = {1}; // on crée une surface à partir de la boucle

//== groupe ==
Physical Line("encastr") = {5}; // on encastrera cette ligne
Physical Point("force") = {5}; // lieu application force
Physical Surface("poutre") = {1}; // notre poutre 2D

maillage 2D

Et poutre3d.geo qu’on maille en 3D avec gmsh :

//== paramètres: ==
//taille maillage autour des nœuds.
cl__1 = 5;
L=100; // longueur poutre
R=5; // ratio longueur/largeur
l=L/5;

//== géométrie ==
//points
Point(1) = {0,0, 0, cl__1};
Point(2) = {L,0, 0, cl__1};
Point(3) = {L,l, 0, cl__1};
Point(4) = {0,l, 0, cl__1};
Point(5) = {L, l/2, 0, cl__1};
//lignes
Line(1) = {1, 2};
Line(2) = {2, 3};
Line(3) = {3, 4};
Line(4) = {4, 1};
//surface
Line Loop(1) = {1, 2, 3, 4};
Plane Surface(1) = {1};
Point{5} In Surface{1}; // pour que le point 5 soit contenu dans la surface

//volume
Extrude {0,0,-3}{Surface{1};Layers{3}; Recombine;}
//on extrude la surface 1 de -3mm selon laxe Z
//en créant 3 éléments dans l’épaisseur avec laide de calques


//== groupe ==
//on sait que cest la surface 25 parce quon le visualise sous gmsh en affichant « surface label ».
//il peut y avoir une erreur lors de limportation si le numéro de la surface créée par lextrusion nest pas 25.
//      Cest pas grave, on regarde à quoi correspond la surface à encastrer, on trouve son label, et mon modifie les lignes ci-dessous.
Physical Surface("encastr") = {25}; // on encastrera cette surface
Physical Point("force") = {5}; // lieu application force
Physical Volume("poutre") = {1}; // notre poutre 3D

//== maillage ==
Transfinite Line{1,3}=8*R+1; // 8*R élém dans la longueur = 41 nœuds entre lignes 1 et 3
Transfinite Line{4,2}=8+1; // 8 élém dans la largeur =  9 nœuds entre lignes 4 et 2
Transfinite Surface "*"; // on veut un maillage propre
Recombine Surface "*"; // on veut un maillage quadra

maillage 3D

Nous voici maintenant avec trois maillages au format .med. Il nous faut maintenant créer notre fichier de commandes !

Fichier de commandes

#U1.03.02
DEBUT();

#on charge le fichier de maillage .MED, unité logique 20
mesh=LIRE_MAILLAGE(
    INFO=2,
    INFO_MED=2,
    UNITE=20,
    FORMAT='MED',
);

#on a importé le maillage et ses groupes, on crée d'autres groupes:

mesh=DEFI_GROUP(
    reuse =mesh,
    INFO=2,
    MAILLAGE=mesh,
    #on crée un groupe nommé TOUT qui contient toutes les mailles du maillage.
    #on ne va pas s'en servir, mais ça peut être utile
    CREA_GROUP_MA=_F(NOM='TOUT',TOUT='OUI',),
    #on crée un groupe de nœuds qui contient tous les nœuds de toutes les mailles.
    # Il faut le faire quand le maillage provient de Gmsh, car Gmsh transforme les nœuds en maille, on les retransforme ici en nœuds
    CREA_GROUP_NO=_F(TOUT_GROUP_MA='OUI',),
);

#on affecte au groupe de mailles 'poutre' créé avec gmsh,
#   des éléments finis de types Poutre, ici POU_D_T
model=AFFE_MODELE(
    MAILLAGE=mesh,
    AFFE=(
        _F(
          GROUP_MA=('poutre',),
          PHENOMENE='MECANIQUE',
          MODELISATION='POU_D_T',
        ),
    ),
);

#on définit un matériaux, ici de l''acier:
#  Module d'Young' E = 210000 N/mm2
#  Coefficient de Poisson, nu = 0.3
#  masse volumique = 8e-9 tonne/mm3
steel=DEFI_MATERIAU(ELAS=_F(E=210000.,NU=0.3,RHO=8e-9),);

#U4.43.03
#on assigne notre matériaux à nos mailles du groupe 'poutre'
material=AFFE_MATERIAU(
    MAILLAGE=mesh,
    AFFE=_F(GROUP_MA=('poutre',), MATER=steel,),
);


#U4.42.01
#On assigne à nos éléments poutre POU_D_T une section rectangulaire de largeur 20 mm et d’épaisseur 3 mm

elemcar=AFFE_CARA_ELEM(
    MODELE=model,
    INFO=2,
    POUTRE=(
        _F(
            GROUP_MA=('poutre',),
            SECTION='RECTANGLE',
            CARA=('HY','HZ',),
            VALE=(3,20),
        ),
    ),
);
#on interdit toute rotation et translation aux nœuds du groupe 'encastr' (1 seul nœud ici).
#   cela simule l'encastrement
encast=AFFE_CHAR_MECA(
    MODELE=model,
    DDL_IMPO=(
        _F(
            GROUP_NO=('encastr',),
            DX=0,DY=0,DZ=0,DRX=0,DRY=0,DRZ=0,
        ),
    ),
    INFO=1,
);

# on applique 500 N selon la direction -Z au nœud de notre groupe 'force'
force_f=AFFE_CHAR_MECA(
    MODELE=model,
    FORCE_NODALE=_F(
        GROUP_NO=('force',),
        FZ=-500,
    ),
    INFO=2,
);

#U4.51.01
#on compile les précédents concepts pour le calcul
stat=MECA_STATIQUE(
    MODELE=model,
    CHAM_MATER=material,
    CARA_ELEM=elemcar,
    EXCIT=(
        _F(CHARGE=encast,),
        _F(CHARGE=force_f,),

    ),
);

# Par défaut, sont calculés uniquement les déplacements et les réactions nodales aux points de Gauss des éléments, je crois.
# du coup on enrichit le concept "stat" pour lui demander d'autres choses.
# SIEF_ELNO: ici, efforts théorie des poutres au niveau des nœuds des éléments
# SIPO_ELNO: ici, contraintes dans la poutre, au niveau des nœuds des éléments
# SIPM_ELNO: ici, contrainte max dans la poutre
# REAC_NODA: forces/moments aux nœuds limites
stat=CALC_CHAMP(
    reuse =stat,
    RESULTAT=stat,  
    CONTRAINTE=(
        'SIEF_ELNO','SIPO_ELNO','SIPM_ELNO',
    ),
    FORCE=('REAC_NODA',),
);

#on imprime ça dans un fichier de sortie .med, unité logique 80.
#on n'imprime que les déplacements et les contraintes
# (on n'affiche pas tout ce qu'on a calculé, genre SIPM_ELNO ou REAC_NODA pourquoi pas !)
IMPR_RESU(
    FORMAT='MED', 
    UNITE=80,
    RESU=_F(
        RESULTAT=stat,
        NOM_CHAM=(
            'DEPL',
            'SIPO_ELNO',
            'SIPM_ELNO',
        ),
    ),
);

FIN();

Notez que les #U4.51.01 ou autres renvoient à la documentation.
On enregistre ce fichier texte en 1d.comm, par exemple, et nous allons lancer le calcul à l’aider d’astk.

Astk

Astk est l’outil permettant de mener à bien un calcul, on le lance via /opt/code_aster/bin/astk (si vous avez installé Code_Aster dans /opt).

On cherche à obtenir une fenêtre qui a cette allure :
astk

Ensuite :

  • FileNew ;
  • on choisit notre dossier de travail (path) ;
  • dans la colonne d’icônes au milieu à droite, on clique sur l’icône en forme de dossier bleu, pour aller chercher son mesh1d.med et son 1d.comm ;
  • on clique sur l’icône du dessus pour ajouter deux lignes, puis dans type pour la ligne, on choisit mess et rmed, dans name on les appelle ./log1d.mess et ./resu1d.rmed ;
  • FileSave_As1d.astk.

  • File -> New

  • on choisit notre path / dossier de travail

  • dans la colonne d'icônes au milieu à droite, on clique sur l’icône en forme de dossier bleu, pour aller chercher son mesh1d.med et son 1d.comm

  • on clique sur l’icône du dessus pour ajouter deux lignes, puis dans type pour la ligne, on choisit mess et rmed, dans name on les appels ./log1d.mess et ./resu1d.rmed

  • File -> Save_As -> 1d.astk

La colonne LU correspond à Logical Unit ou Unité Logique, c’est l’endroit de la mémoire où je ne sais quoi où l’on s’attend à trouver le fichier ; dans fichier.comm, on a précisé que l’unité logique était 20 pour le maillage .med et 80 pour le résultat .med. Les colonnes DRC veulent dire Données, Résultats, Compressé.

Une fois que cela est fait on clique sur Run ! Le calcul est lancé. Il se termine, on va voir le log1d.mess qui a été créé, il contient toutes les infos relatives au calcul. L’information la plus importante étant la dernière ligne.

Chez moi j’ai : EXECUTION_CODE_ASTER_EXIT_13223-localhost=0. Si le code renvoie 0, c’est que cela a fonctionné ! S’il renvoie 1, c’est que ça a planté et qu’il faut déboguer…

Résultat

Normalement tout a fonctionné, nous avons un beau resu1d.rmed que nous ouvrons avec gmsh (terminal gmsh resu1d.rmed).

On peut donc voir les déplacements et la contrainte, tout ce dont a besoin un mécanicien pour dimensionner des systèmes mécaniques !

Voici les paramètres sur lesquels agir pour afficher le déplacement multiplié par 10. Il faut afficher des Vectors et non pas l’Original Field. Comme ci‐dessous :
gmsh poutre 1D

Pour les contraintes, SIPO_ELNO contient la contribution de chaque force ou moment aux contraintes de la poutre.

C’est grosso modo un vecteur de six composantes que voici :
contraintes

Pour les afficher une par une, on se place dans OptionsVisibility et, en bas, la première case à droite de la liste déroulante Original Field/Scalar Force/Vector/Tensor. Zéro correspond à SN et cinq correspond à SNT, par rapport au tableau ci‐dessus (je ne sais pas trop ce que présente SIPO_ELNO par défaut).

SIPM_ELNO, quant à lui, représente par défaut la contrainte maximum selon XX.

Voici d’autres visualisations avec les modèles 2D et 3D :
2d_vmises
3d_déplacement
3d_vmises

Aller plus loin

Code_Aster est très vaste, il contient près de 400 types d’éléments finis ! Pour aller plus loin, n’hésitez pas à lire la doc, qui contient aussi des exemples de calculs qui sont livrés avec le code.

Je vous conseille aussi notamment l’excellent livre sous licence libre de Jean‐Pierre Aubry, qui est un passage obligatoire pour prendre en main le code ! Le code date, en revanche, de la version 11 de Code_Aster ; mais une nouvelle version est en cours d’écriture !
On y fait notamment des analyses non linéaires avec du contact entre pièces et du frottement.
Aster Study vient aussi de faire son apparition.

Voilou, cher lecteur. N’hésite pas à t’amuser !

Je poste en commentaire les fichiers .comm de calcul en 2D et 3D.

Aller plus loin

  • # Un bel article

    Posté par  . Évalué à 10.

    Merci pour cet article complet et documenté, qui sera sûrement très utile à quiconque veut démarrer avec code_aster.

    Quelques précisions sur la section "astk" :

    • LU signifie "Logical Unit" et si on met l'interface en français, on aura UL (Unité Logique) qui est un concept utilisé en Fortran pour manipuler les fichiers d'entrée et de sortie ;
    • DRC signifie Données/Résultats/Compressé.

    L'équipe de développement code_aster et Salome-Meca.

  • # paquet debian

    Posté par  . Évalué à 4.

    Merci pour le tuto.

    Il y a des paquets debian.
    Est-ce que c'est suffisant et les outils à compiler que tu proposes sont plus complet ?

    • [^] # Re: paquet debian

      Posté par  . Évalué à 5.

      La version proposée dans le paquet debian n'est pas très récente. Mais si c'est pour reproduire un tutorial qui date de la même époque, ça peut être pratique.

      Si vous compilez le code, une version stable est disponible sur leur site, c'est probablement le meilleur choix.

      Sinon, le binaire de Salome-méca (1.4 Go) sera très bien.

    • [^] # Re: paquet debian

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Il y a aussi des paquets pour FreeBSD.

      J’essaye de les tenir à jour, mais le portage n’est pas toujours simple, et il est déjà arrivé que certaines versions prennent un peu de retard…

    • [^] # Re: paquet debian

      Posté par  . Évalué à 4.

      J'utilise Fedora et personne n'a construit de paquet pour ce système. J'ignore ce que contient le paquet Debian, mais il semble que la version du code utilisé ait 5 ans.

      Comme dis plus haut, je conseillerais donc la compilation ou bien le binaire contenu dans Salome-Méca.

    • [^] # Re: paquet debian

      Posté par  (site web personnel) . Évalué à 6.

      Ca fait un moment que Aster n'a pas shippé dans Debian et a été supprimé depuis.

  • # Dépêche et fichiers de commandes

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Je poste en commentaire les fichiers .comm de calcul en 2D et 3D.

    Ces fichiers sont restés sur le journal d’origine.

  • # Super article

    Posté par  . Évalué à 10.

    Code_Aster est le code OpenSource de FEM orienté mécanique le plus complet, il est réalisé par des chercheurs et ingénieurs dans un esprit de collaboration assez rare dans le milieu académique.

    Ton introduction est très intéressante car tu mets les "mains dans le cambouis", il est possible aujourd'hui de faire une simulation complexe à l'intérieur de Salome-Méca sans éditer manuelement des fichiers textes, cela se rapproche plus de ce que les étudiants en méca connaissent, avec des plateformes comme Abaqus ou ANSYS. La nouvelle mouture intégrée de Salome-Meca étant encore jeune, il n'y a pas encore profusion de supports mais on peut tout de même noter l'apparition de plusieurs tutoriels vidéos assez intéressant (n'ayant pas trop besoin je ne les ai que parcouru). A noter également la chaîne de Code_Aster avec des choses assez intéressantes comme des études de sensibilité.

    Vive la mécanique libre !

    • [^] # Re: Super article

      Posté par  (site web personnel) . Évalué à 5.

      Question très bête, est-ce que ce genre de simulateur peut faire son chemin dans blender pour avoir un comportement mécanique réaliste dans un film ?

      "La première sécurité est la liberté"

      • [^] # Re: Super article

        Posté par  . Évalué à 5.

        J'imagine mal ce genre de chose se faire.
        La simulation à éléments finis a pour but d'obtenir des résultats les plus précis possibles, et ça prend donc un certain temps de calcul, non pour "rendre" la scène, mais simplement pour déterminer les déformations, contraintes, etc.
        Blender a pour but de faire de l'animation. Le rendu est la pièce maîtresse. Pour ça, il est désirable d'avoir des simulations mécaniques assez simplifiées pour qu'elles ne soient pas un élément bloquant du rendu.

        Peut-être qu'on peut demander ça dans l'autre sens: est-ce que Blender pourrait un jour être utilisé pour une visualisation des résultats (ça en jetterait pas mal dans les présentations…).

        • [^] # Re: Super article

          Posté par  (site web personnel) . Évalué à 3.

          Tu as raisons aussi, mais je pensais que un des défis de la simu mécanique est la simplification du maillage. On peut donc imaginer un truc simplifié pour une "simu blender".

          De toute façon, le mouvement est l'intégration des simulateurs entre eux. Or, il est impossible pour une seul personne de maitriser l'ensemble des techniques de contournement des limitations des simulateurs (méca, fluide, électronique, logique, électromagnétique,…), il faut donc simplifier l'accès.

          "La première sécurité est la liberté"

          • [^] # Re: Super article

            Posté par  . Évalué à 7.

            Dans l'absolu, l'idée peut sembler intéressante mais c'est souvent assez compliqué car cela dépend beaucoup des objectifs de chacun.
            Par exemple je peux te parler des simulateurs biomédicaux de déformation, car je travaille dessus. Nous avons collaboré avec une équipe qui travaillait plutôt avec des outils comme blender et codait son propre environnement de simulation mais leurs objectifs étaient vraiment différents des autres. Il voulaient avoir quelque chose de "réaliste" qui ressemble à la réalité mais qui soit en temps réel, alors que nous avons besoin de code dont nous maîtrisons les erreurs et notre contrainte à cette époque était la simulabilité du calcul pour avoir les résultats les plus exactes possibles si le calcul prenait une journée ce n'était pas grave.
            Leur code bien que basé sur les mêmes théories ne permettait pas d'augmenter le nombre d'éléments dans le maillage car cela n'aurait pas permis le temps réel et donc en dehors de leurs préoccupations. La manière de découper les concepts mathématiques sous-jacent n'étaient pas celle que nous utilisions, il nous était donc impossible d'apporter notre expertise.
            Il faut bien comprendre que ces outils sont des outils d'experts dont l'objectif et de pouvoir prédire de manière la plus fine possible les risques de défaillance (ici les risques sur les centrales nucléaires), une attention toute particulière est donc apportée à l'évaluation des erreurs et la possibilité d'augmenter la finesse des maillages. Ainsi les outils développés sont plutôt de nature à aller attaquer des cluster de calculs plutôt que de faire des simulations multi-physique sur ton PC.

            Malheureusement simplifier l'accès est nécessaire mais ne change rien au fait qu'avoir les connaissances pour évaluer une simulation dans différentes physique nécessite la compréhension de ces physiques. Tout les calculs sont basés sur des approximations et modèles et qui doivent être compris ainsi que leur limites intégrées par leurs utilisateurs.

            Après pour les simus dans blender en vu de rendu réaliste, le talents des gens qui font les moteurs de rendu est d'intégrer des équations aux dérivées partielles et ordinaires adaptées au rendu, d'avoir des modèles de collision "réaliste" et le tout dans une temps compatible avec la génération d'une séquence temporelle extrêmement longue, autant dire que le travail de développeur de moteur de rendu n'est pas prêt d'être remplacé par celui des scientifiques des edp.

            • [^] # Re: Super article

              Posté par  (site web personnel) . Évalué à 4.

              Ainsi les outils développés sont plutôt de nature à aller attaquer des cluster de calculs plutôt que de faire des simulations multi-physique sur ton PC.

              Avec l’avènement du cloud computing, cela va être de moins en moins vrai. Il ne parait pas déconnant d'avoir plusieurs simulateur open source qui tournent sur 30 machines chez OVH.

              "Malheureusement simplifier l'accès est nécessaire mais ne change rien au fait qu'avoir les connaissances pour évaluer une simulation dans différentes physique nécessite la compréhension de ces physiques. Tout les calculs sont basés sur des approximations et modèles et qui doivent être compris ainsi que leur limites intégrées par leurs utilisateurs. "

              Je comprends bien. C'est la façon de voir une simulation aujourd'hui. Mais avec le multiphysique, c'est juste impossible. On ne peut pas être spécialistes de tout.

              De plus, ses outils sont en général possible uniquement pour les grosses boites avec de grosses équipes qui peuvent se payer les outils ansys. Pourtant ce genre de prototypage numérique a un avantage énorme en terme de vitesse de dev et de précision, et cela intéresse forcément les PME.

              Après pour les simus dans blender en vu de rendu réaliste, le talents des gens qui font les moteurs de rendu est d'intégrer des équations aux dérivées partielles et ordinaires adaptées au rendu, d'avoir des modèles de collision "réaliste" et le tout dans une temps compatible avec la génération d'une séquence temporelle extrêmement longue, autant dire que le travail de développeur de moteur de rendu n'est pas prêt d'être remplacé par celui des scientifiques des edp.

              ok, je pensais qu'avec la mode des ROM (reduced order model) qui permettent justement la simulation en temps-réel, cela serait possible.

              "La première sécurité est la liberté"

              • [^] # Re: Super article

                Posté par  . Évalué à 3.

                ok, je pensais qu'avec la mode des ROM (reduced order model) qui permettent justement la simulation en temps-réel, cela serait possible.

                En théorie cela est possible, mais 99% de ces méthodes (PGD,POD, SuperElement, …) sont aujourd'hui adaptées à l'élasticité linéaire ce qui est très rarement ce que l'on a besoin de simuler. Donc au final on ne peut pas les utiliser.

        • [^] # Re: Super article

          Posté par  . Évalué à 3.

          Au fait y en a qui utilise déjà Blender pour faire de l'optimisation topologique : ici

          Mais en effet, je ne pense pas que l'animation ait du temps de calcul à perdre pour ce genre de détails qu'ils approchent déjà très bien.

  • # Petite question

    Posté par  . Évalué à 9. Dernière modification le 08 janvier 2018 à 17:38.

    Salut,

    Bon j'allais poser la question suivante, mais j'ai trouvé la réponse. Je la mets quand même au cas où d'autres se la posent :

    Pourquoi définis-tu le modèle 2D avec 5 points comme ceci:

          ^    
        l | (4)                (3)    
          |                    (5)    
        0 | (1)                (2)    
         -|-------------------------->    
          0                    L    
    

    Puis ensuite relier faire un rectangle 1-2-5-3-4-1 plutôt que de définir uniquement un rectangle avec les points 1-2-3-4-1 ?

    La réponse est probablement car tu veux appliquer la force ponctuellement au point 5 ?

    J'ai l'impression qu'en 3D tu définis simplement le rectangle avec 1-2-3-4-1 puis que tu utilises une autre façon d'appliquer la force en 5 sans avoir besoin de l'utiliser pour la définition de la forme. Est-ce que c'est possible en 2D aussi ?

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Petite question

      Posté par  . Évalué à 6.

      Salut,
      En effet, dans la géometrie en 2D, si je ne place pas de point 5 à ce niveau, je ne suis pas sûr que le mailleur y fasse passer un noeud sur lequel je pourais appliquer ma force, et s'il le fait je ne connaîtrais pas à l'avance l'id du noeud . Là je sais que mon noeud sera bien placé au milieu et que ce se sera le noeud numéro 5.
      Je crée donc une boucle 1-2-5-3-4-1 que je transforme en surface: elle contient mon point 5 donc mon noeud 5.

      Pour le modèle 3D, j'aurais pu faire la même chose, mais j'ai choisi une autre méthode:

      Je crée une boucle 1-2-3-4, puis la surface 1 relative à cette boucle. Si je maille ainsi en 2D, ma surface 1 n'a aucun lien avec le point 5 et le mailleur n'a donc aucune raison de faire coïncider un nœud sur le point 5.

      Pour contrer à cela, j'ajoute la ligne :

      Point{5} In Surface{1}; // pour que le point 5 soit contenu dans la surface 1

      Ainsi le point 5 fait maintenant partie de ma surface 1, que j'extrude ensuite.

      C'est tout à fait possible en 2D, la seule chose qui change entre la 2D et la 3D c'est l'extrusion, et une façon de mailler.

      En espérant avoir été clair. :)

  • # Météo

    Posté par  (Mastodon) . Évalué à 5.

    Une fois n’est pas coutume, il pleut en Haute‐Garonne !

    T'étais où depuis novembre ? :)

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.