Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Hello all,
1- What is the correct way of attaching 3D elements to Coque3D or DKT elements? Should it be done just by sharing nodes or LIAISON in AFEE_CHAR_MECA should be employed?
2- Same about attaching 3D elements to spring/mass/damper. Is it done by duplicating the interface node and coupling dofs of these nodes by LIAISON_DDL? If so, since there is no mismatch between number of dofs between two element types, I cannot understand the reason.
Thanks in advance
Nima
Last edited by Nima (2010-06-23 00:08:40)
Offline
Hi Nima,
to attach 3D element with COQUE3D or DKT there is the ARLEQUIN command but this command have some problem.
Another idea could be use the approach used on:
http://www.code-aster.org/forum2/viewtopic.php?id=12138
If you needed to understand the stresses in coupling zone after you can do a submodel of the interested area.
About the discret element it's depend what do you want, but there are a lot of command as Liaison_Solide, Liaison_DDL and more.
Best Regards
Jacopo
Salome-Meca 2017.02 (Intel Xeon 8 Core x 2 RAM 32GiB) Ubuntu 16.04 LTS
Offline
Hello,
Since 10.1.19, you have a new functionality in LIAISON_MAIL which is detailed here : (fiche 13381)
http://www.code-aster.com/documents/histor/10.1.19.txt
It allows to connect 3D with shell elements.
Best regards !
Sébastien Meunier - EDF Lab Les Renardières
Offline
Dear Sebastien,
Thank you for the hint about LIAISON_MAIL.
I have a small question regarding the kind of modelling it allows. It is indicated in the histor.txt:
COQUE_MASSIF :
On écrit l'égalité des translations et des rotations (DX,DY,DZ,DRX,DRY,DRZ) du noeud
"esclave" (de type "coque") avec les translations de 3 points (3D) en vis à vis dans les
mailles "maitre" (A, A+h/2, A-h/2)
En notant :
* A le point 3D géométriquement en vis à vis
* h un petit vecteur normal à la coque dont la longueur est l'épaisseur de la coque
MASSIF_COQUE :
On écrit l'égalité des translations (DX,DY,DZ) du noeud "esclave" (de type "3D") avec
les translations et rotations du point (coque) en vis à vis dans la maille "maitre".
To translate it briefly in english, does it mean that:
- COQUE_MASSIF doesn't necessitate shared nodes between the solid and the shell: there is a projection of translation/rotation on the shell nodes from the way the face of the solid moves: from the 3 geometrical points on the face of the solid, it is possible to evaluate translations and rotations and apply them to the shell
- MASSIF_COQUE needs shared nodes between shell and solid and basically, I guess that rotations at solide-side are computed to the shared node to spread them in the shell
Do I undestand well?
In the first case (COQUE_MASSIF), if indeed it is a projection may I ask if it works backwards? (from shell to solid) and what are the pre-requesites regarding contact between elements to have a "safe" behaviour? I mean, does it also work when shell and solide are far away from each other?
I thank you in advance.
Best regards,
Pierre
Offline
Pierre,
Thomas De Soza m'a dit que vous parliez français alors, comme pour moi, l'anglais c'est du chinois ...
Pour le mot clé LIASION_MAIL, les noeuds "esclaves" et "maitres" sont en principe distincts, car le développement a été fait pour des maillages incompatibles.
La différence entre MASSIF_COQUE et COQUE_MASSIF est dans la nature des relations linéaires qui sont écrites entre les ddls esclaves et les ddls maitres.
Pour MASSIF_COQUE par exemple (qui a ma préférence), soit N2 un noeud esclave (de type "massif").
On repère le point de la coque A qui est le plus proche de N2 (normalement, N2 est sur la normale de la coque en A et A est au "bord" de la coque).
A appartient à 1 élément de coque particulier. Si cet élément est un TRIA3, et puisque A est en principe sur son bord, on peut écrire :
A=c1*NC1 + c2*NC2 (avec c1+c2=1. et NC1 et NC2 deux noeuds de coque).
On écrit 3 relations linéaires pour éliminer les 3 translations du noeud N2.
Par exemple pour DX et en supposant que l'élement de coque est dans le plan OXY :
DX(N2)= DX(A) +h*DRY(A) (h étant la distance entre N2 et A selon la normale de la coque)
ou plus précisément :
DX(N2)= c1*DX(NC1)+c2*DX(NC2) + h*(c1*DRY(NC1)+c2*DRY(NC2))
En espérant avoir été plus clair que dans l'histor.
Cordialement
Jacques
Offline
Bonjour M. Pellet,
Je vous remercie pour ces informations.
A vrai dire, ma question portait plus sur l'aspect "domaine de validité" de l'algorithme:
Est-ce "valide" d'appliquer ce mécanisme dans le cas d'éléments "loin" l'un de l'autre?
Si non, quelle est la "distance" de validité?
En lisant votre description, je m'aperçois de plus que j'avais mal compris le domaine d'application de cette option de LIAISON_MAIL.
LIAISON_MAIL semble plutôt s'appliquer au cas 2 de l'image ci-jointe plutôt qu'au cas 1, car dans ce cas 1, je n'arrive pas à donner du sens à votre explication:
normalement, N2 est sur la normale de la coque en A et A est au "bord" de la coque
Est-ce bien cela?
Je vous remercie par avance pour votre retour.
Cordialement,
Pierre
Offline
Bonsoir,
Je suis aussi nul en dessin qu'en anglais ...
L'objectif n°1 de cette liaison est de pouvoir remplacer un morceau de coque par un "patch" maillé en 3D. Il me semble que cela ressemble plutot à votre cas 1.
Je joins ci-dessous une image qui illustrera prochainement une "news" du site.
Ce qui est attendu du code, c'est que les noeuds "massifs" liaisonnés aux noeuds de coque soient ceux de la trace de la coque (avec son épaisseur) sur le modèle 3D.
Sur l'image jointe, on voit que le modèle 3d est plus "fin" que celui de la coque : il existe plusieurs éléments 3d dans l'épaisseur de la coque.
Bonjour M. Pellet,
Je vous remercie pour ces informations.
A vrai dire, ma question portait plus sur l'aspect "domaine de validité" de l'algorithme:
Est-ce "valide" d'appliquer ce mécanisme dans le cas d'éléments "loin" l'un de l'autre?
Si non, quelle est la "distance" de validité?En lisant votre description, je m'aperçois de plus que j'avais mal compris le domaine d'application de cette option de LIAISON_MAIL.
LIAISON_MAIL semble plutôt s'appliquer au cas 2 de l'image ci-jointe plutôt qu'au cas 1, car dans ce cas 1, je n'arrive pas à donner du sens à votre explication:normalement, N2 est sur la normale de la coque en A et A est au "bord" de la coque
Est-ce bien cela?
Je vous remercie par avance pour votre retour.Cordialement,
Pierre
Offline
Thank you all for your explanations. I tried ARLEQUIN but i had no success until now because of some problem in my element numbering. I will try to solve this problem. For trying LIASION_MAIL I need to update my installation.
A- Shell-Solid coupling:
Solid and shell structures in my case have a shared border with each other (as in the attached picture). I think both ARLEQUIN and LIASION_MAIL's new options are more oriented toward incompatible meshes. Can ARLEQUIN and LIASION_MAIL be used for compatible meshes where nodes are shared at the border between solid and shell structures?
I assume both MASSIF_COQUE and COQUE_MASSIF options give the same results. Is there any difference in results between these two options?
B- Discrete-Solid coupling:
Re: Jocopo's note. I am trying to truncate my structure from a point forward and use spring, mass and dashpot to represent what is beyond that point in my model. To do so I selected one node of a solid element at the surface at that end (N1) and generated two more nodes (N2 & N3) on a straight line with N1. I created two SEG2 edge elements between N1-N2 (M1) & N2-N3 (M2). Then I fixed (DX=DY=DZ=0) N3, Defined N2 as a lumped mass, M1 as a spring and M2 as a dashpot like below:
...
DISCRET=(_F(REPERE='LOCAL',
CARA='K_T_D_L',
MAILLE='M1',
VALE=(K_LUMP,0,0,),),
_F(REPERE='GLOBAL',
CARA='M_T_D_N',
NOEUD='N2',
VALE=M_LUMP,),
_F(REPERE='LOCAL',
CARA='A_T_D_L',
MAILLE='M2',
VALE=(C_LUMP,0,0,),),),);
Should I use LIAISON_DDL for this purpose? I tried LIAISON_DDL but there was no difference in the result? However there may be a problem in another part of the model which causes lack of sensitivity in this part (e.g. weak treatment of coupling between shell and solid parts)
Thanks again
Nima
Last edited by Nima (2010-06-08 18:34:47)
Offline
Hello,
I give some advices for question A. I am not competent for question B
I think you can use LIAISON_MAIL and Arlequin with compatible meshes as you want. There should be no particular problems, ... in theory !
For LIAISON_MAIL, results should not be the same for MASSIF_COQUE and COQUE_MASSIF because prescribed linear relations are not the same, like Jacques mentioned. MASSIF_COQUE should lead to better and smoother results.
For ARLEQUN, I just remind you that shell elements must penetrate massive part to have a gluing zone, where linear relations are enforced. Some test cases illustrate it (sslv145 and sslv152).
Actually, the philosophy of these 2 methods is not the same. With LIAISON_MAIL, you prescribe cinematic relations at the interface between the 2 models and with Arlequin, you minimize the total energy of the model by weighting each model.
Best regards and good luck for your work !
Sébastien Meunier - EDF Lab Les Renardières
Offline
Hello,
I installed NEW10/10.1.27. I don't have these new LIAISON_MAIL options in eficas. Were these new options added to the eficas catalog?
I used Courtois' note to update the catalog:
http://www.code-aster.org/forum2/viewto … ?pid=21465
Nima
Offline
Thank you for updated documentation. Few more points:
1- ssls101m and ssls101n are not included in histor files.
2- When I introduced the following in the comm file:
LIAISON_MAIL=_F(TYPE_RACCORD = 'MASSIF_COQUE',),
aster did not recognize TYPE_RACCORD and I got this error:
JDC.py : ERREUR A L'INTERPRETATION DANS ACCAS - INTERRUPTION
>> JDC.py : DEBUT RAPPORT
CR phase d'initialisation
Etape : AFFE_CHAR_MECA ligne : 3333 fichier : 'fort.1'
Mot cle Facteur :LIAISON_MAIL
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Règle(s) non respectée(s) : - Il faut au moins un mot-clé parmi : !
! ('GROUP_MA_MAIT', 'MAILLE_MAIT') !
! !
! - Il faut au moins un mot-clé parmi : ('GROUP_MA_ESCL', 'MAILLE_ESCL', !
! 'GROUP_NO_ESCL', 'NOEUD_ESCL') !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Mots cles inconnus :TYPE_RACCORD !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Fin Mot cle Facteur :LIAISON_MAIL
Fin Etape : AFFE_CHAR_MECA
fin CR phase d'initialisation
>> JDC.py : FIN RAPPORT
FIN EXECUTION
EXECUTION_CODE_ASTER_EXIT_26169=1
Is anything wrong with the installation? After solving this error, I guess more details are needed for MASSIF_COQUE like solid elements group, shell group and shared nodes but I don't know the syntax you used and eficas lacks pertinent catalog entry in cata.py.
Any ideas?
Thanks
Nima
Offline
Hello,
It is strange that ssls101m and ssls101n do not exist because their documentation exist on the website ... You should look for MASSIF_COQUE in the directory $ASTER_HOME/NEW10/catapy/commande/affe_char_meca.capy. If this keyword doesn't appear, it means that your update failed.
Just by curiosity, did you manage to make your test with Arlequin ?
Best regards !
Last edited by sébastien meunier (2010-06-11 22:41:41)
Sébastien Meunier - EDF Lab Les Renardières
Offline
Thanks Sébastien,
I didn't continue with ARLEQUIN once I learned from your message that shell structure should penetrate the solid structure. In my case I cannot make it penetrate since it is a biological structure and I don't want to do something that I don't have any physiological explanation for it.... I may be wrong with this attitude
It seems that my updating has some problem because I don't have anything about MASSIF_COQUE in affe_char_meca.capy. I reinstalled it but I still have the same problem....
Regards,
Nima
Offline
Thanks again Sébastien for your hint. My NEW10 installation had a problem which was solved. Now I have this error:
!--------------------------------------------------------------------------------------------!
! <A> <CALCULEL5_49> !
! !
! LIAISON_MAIL : !
! La relation linéaire destinée à éliminer le noeud esclave N3 est une tautologie !
! car la maille maitre en vis à vis de ce noeud possède ce meme noeud dans sa connectivité. !
! On ne l'écrit donc pas. !
! !
! !
! Ceci est une alarme. Si vous ne comprenez pas le sens de cette !
! alarme, vous pouvez obtenir des résultats inattendus ! !
!--------------------------------------------------------------------------------------------!
It seems that its because of using compatible mesh. Am I correct?
Regards,
Nima
Offline
Hoi
you can find an example of the Arlequin method here:
http://www.caelinux.org/wiki/index.php/ … l/arlequin
The comparison with LIAISON_SOLIDE is given as well.
kind regards - kees
Last edited by keeswouters (2013-04-30 10:55:49)
kind regards - kees
--
I a parallel univers the laws of mechanics may be different.
Offline
Hi,
Please help! Any comment on my last post about errors is greatly appreciated.
Nima
Offline
Hoi Nima
this works for me:
chnorm = CREA_CHAMP(TYPE_CHAM='NOEU_GEOM_R',
OPERATION='NORMALE',
MODELE= SVmodel,
GROUP_MA='shell',
INFO=1);
ConShSol=AFFE_CHAR_MECA(MODELE=SVmodel,
LIAISON_MAIL =_F(TYPE_RACCORD='COQUE_MASSIF',
#GROUP_NO_ESCL='Cline',
GROUP_MA_ESCL='Cline',
GROUP_MA_MAIT='block',
CHAM_NORMALE=chnorm,
EPAIS=thickness,))
where 'shell' is a shell or 2D plate, 'Cline' is an edge, and 'block' is a 3D block.
I didnot test the other way around: TYPE_RACCORD='MASSIF_COQUE'.
Edit: there is an example of the TYPE_RACCORD='MASSIF_COQUE' connection in the previous link.
Kind regards - kees
Last edited by keeswouters (2010-06-20 11:53:13)
kind regards - kees
--
I a parallel univers the laws of mechanics may be different.
Offline
Thanks kees for the test. Do your solid and shell parts have compatible meshes? (Do they share nodes?)
Apparently verification case ssls101m worked with MASSIF_COQUE as well but that case has incompatible meshes.
Nima
Last edited by Nima (2010-06-15 21:20:13)
Offline
Nima,
Que les maillages soient compatibles (géométriquement) ou non est peu important. Mais LIAISON_MAIL a été programmé pour des éléments a priori disjoints. Si ce n'est pas le cas, c'est à dire si 1 noeud esclave appartient à une maille "maitre", alors, le code émet l'alarme :
! <A> <CALCULEL5_49> !
! !
! LIAISON_MAIL : !
! La relation linéaire destinée à éliminer le noeud esclave N3 est une tautologie !
! car la maille maitre en vis à vis de ce noeud possède ce meme noeud dans sa connectivité. !
! On ne l'écrit donc pas.
mais ce n'est qu'une alarme et ce n'est pas forcément inquiétant
Thanks kees for the test. Do your solid and shell parts have compatible meshes? (Do they share nodes?)
Apparently verification case ssls101m worked with MASSIF_COQUE as well but that case has incompatible meshes.
Nima
Offline
Hoi Nima, Pellet,
in my case the nodes of the shells and solids do not coincide, as Pellet indicated already.
kind regards - kees
kind regards - kees
--
I a parallel univers the laws of mechanics may be different.
Offline
OK. Let me summarize discussion we had in this thread for future reference. Currently coupling of shell to solid elements can be done using one of the following strategies depending on the nature of the problem:
1- Continuing shell elements to cover some portion of (a) face(s) of the solid part.
2- If penetration of shell part to the solid part is justified, one can use ARLEQUIN.
3- LIAISON_MAIL/MASSIF_COQUE or COQUE_MASSIF can be used if solid and shell parts do not share nodes.
Offline