site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban

You are not logged in.

- Topics: Active | Unanswered

BR/Micke

Hi, No I have not wound a answer.

Regarding the contact problems, -are you using Salome meca 2021? -Have you seen this post:https://code-aster.org/forum2/viewtopic.php?id=26047

I tried your idea with salome bi-quadratic but it seems this does not create PENTA18. It creates PENTA20. I am not sure CA will be able to handle them.

BR/Micke

You can scale it with MODI_MAILLAGE + ECHELLE.

BR/Micke

BR/Micke

Hi,

CARA_ELEM=elemprop, is missing for your STAT_NON_LINE case.

BR/Micke

You can print to .resu file with:

TABLE1=POST_RELEVE_T(ACTION=(

_F(RESULTAT=YOURRESULTAT,POINT=(0.0,0.0,0.0), GROUP_NO='YOURGROUPNAME', INTITULE='YOURGROUPNAME', OPERATION='EXTRACTION',NOM_CHAM='FORC_NODA',RESULTANTE=('DX','DY','DZ'), MOMENT=('DRX', 'DRY', 'DRZ'),MOYE_NOEUD='OUI',),

),);

IMPR_TABLE(TABLE=TABLE1,FORMAT='TABLEAU',);

BR/Micke

Nice solution, Thank you!

I did investigate this a bit further. I printed out coordinates, deformations and nodal forces and check the equilibrium:

COORD=COORDDEPL(:,1:3);

DEPL=COORDDEPL(:,4:6);

FORC_NODA=COORDFORC(:,4:6);

n=length(COORDDEPL(:,1))

i=1; Msum=0;

for(i=1:1:n)

V=COORD(i,1:3)+DEPL(i,1:3);

F=FORC_NODA(i,1:3);

M=cross(V,F);

Msum=Msum+M;

end

Msum

The result for GROT_GDEP and using all Beam nodes is:

Msum =-4.2277e-07 3.4652e-07 -6.6579e-07

Hence the beam moments are zero -OK.

The result for GROT_GDEP and using right end nodes is:

Msum = -9.7829e+08 4.7920e+07 -1.4075e+07

Hence the same result as the reaction on the left end side. As expected.

If I neglect the deformation using V=COORD(i,1:3) I get the results given in the previous posts. E.g. for the right end nodes:

Msum = -9.3282e+08 4.8051e+07 -1.4106e+07

So if my investigation is correct the print out from POST_RELEVE_T and MOYE_NOEUD='OUI’ is without taking the deformation into account in the moment calculation. This works ok for PETIT but not for PETIT_REAC and GROT_GDEP. –Does someone know if it is possible to force it to do so?

BR/Micke

The files/Micke

**mihe**- Replies: 4

Hi,

I am trying out simulations with large rotations and deformations GROT_GDEP. I have a horizontal beam fixed at the left end and at the right end loaded by a vertical surface pressure. The beam bends downwards in the negative z-direction. See attached figure. The pressure load is of type SUIV/follower load. The beam is 1000mm long and the maximum displacement is ~170mm in the negative z-direction.

With DEFORMATION=‘GROT_GDEP’ I get the following displacement at the right end:

DX DY DZ

Right end -9.49071988320817E-02 -1.93657103389098E+01 -1.72476505187015E+02

And the following forces:

RESULT_X RESULT_Y RESULT_Z MOMENT_X MOMENT_Y MOMENT_Z

Beam 1.52710E-10 -2.29193E-10 -4.86864E-09 4.54745E+07 1.31263E+05 -3.13190E+04

Left end -1.44293E+02 2.79228E+05 9.60747E+05 9.78294E+08 -4.79202E+07 1.40746E+07

Right end 1.44293E+02 -2.79228E+05 -9.60747E+05 -9.32819E+08 4.80515E+07 -1.41059E+07

‘Beam’ is the sum of all FORC_NODA of the nodes of the beam volume elements (TETRA10). ‘Right end’ is the force applied at the right end. ‘Left end’ is the reaction at the left end. The MOMENT_X for all the beam nodes is 4.54745E+07 which is 4.54745E+07/9.32819E+08 =5% of the applied MOMENT_X= 9.32819E+08 at the right end. I find this result difficult to understand. That the beam is not in equilibrium regarding moment about X does not make sense.

With DEFORMATION=‘PETIT’ I get the following displacement at the right end:

DX DY DZ

N8 -9.78444452002913E-02 -1.24114888251096E-01 -1.70929183101883E+02

And the following forces:

RESULT_X RESULT_Y RESULT_Z MOMENT_X MOMENT_Y MOMENT_Z

Beam 7.18131E-10 1.03910E-10 1.33582E-09 -4.32727E-07 1.48014E-07 1.75791E-07

Left end -1.30319E+02 2.75596E+05 1.00028E+06 9.72714E+08 -5.00266E+07 1.39103E+07

Right end 1.30319E+02 -2.75596E+05 -1.00028E+06 -9.72714E+08 5.00266E+07 -1.39103E+07

The MOMENT_X for all the Beam nodes is zero and the moment applied at the right end MOMENT_X = 9.72714E+08 is the same as the moment supported at the left end. This result is what I would expect.

See attached files . Is the GROT_GDEP FORCE_NODA calculated correct? –is there some option that need the be specified in CALC_CHAMP for the calculation of FORC_NODA? –or what does it mean that the MOMENT_X is non zero? The beam stress is high in this case ~5000MPa, still I think the equilibrium should be possible to understand.

Here is something similar where it is found that for GROT_GDEP with C_PLAN elements you have to use RELATION='VMIS_ISOT_LINE’: /forum2/viewtopic.php?id=21492 . But I have not found similar information for my case.

Any inputs are appreciated. -How can non zero MOMENT_X for the beam be understood or corrected?

BR/Micke

Hi, Has there been progress since 2016 regarding robust/correct results with POU_D_T_GD elements as mentioned here and in post /forum2/viewtopic.php?id=21253 ?

I tried case (3) from /forum2/viewtopic.php?id=21253 with salome meca 19 and 21. Comparing the mess files I got the same results as back in 2016.

BR/Micke

A different method is to create a "spring" with some structural elements, a temperature history and then let the modulus of elasticity of the structural elements be a function of temperature and hence a function of time. Some advantages: It can handle iteration cutbacks. Also, If I remember correct, you can not use discrete elements in simulation with large displacements. In the end, if you are heading for contact simulation you may also want large displacements.

BR/Micke

Hi, - double check the latest documentation:

"lamda : eigenvalue ( lamda=−mu with mu multiplying coefficient of loading)"

"Note: It is well the critical load factor mu and not lamda who is stored in the concept result."

BR/Micke

**mihe**- Replies: 2

Hi, A Question about CREA_MAILLAGE HEXA20_27, PENTA15_18 and the conformity of the mesh.

HEXA27 is recommended for contact analysis(u4.44.11, u2.04.04, u4.23.02) and my experience is that for contact with friction it is a huge difference in converges compared to other elements. At least for FORMULATION='CONTINUE’.

But there is extra effort building the mesh. Building a combined mesh with HEXA20 and PENTA15 can often be easier. However it may then become complicated to convert the mesh into a HEXA27 mesh since CREA_MAILLAGE with keyword HEXA20_27 only modifies QUAD8 and HEXA20 elements (into QUAD 9 and HEXA27).

If you convert a combined HEXA20+PENTA15 mesh using HEXA20_27=_F(TOUT='OUI’) , then on the QUAD sides of the PENTA15 you will get QUAD9 elements that do not conform with the underlying PENTA15. The problem is not solved by sequentially adding the PENTA15_18 operation. QUAD9 elements will then exist on the quad sides of the PENTA18 but the elements will not be joined at the mid side node. The end result is a mesh where you can not use the quad side elements of the pentas.

Questions:

1 -If converting a combined mesh HEXA20+PENTA15 mesh using HEXA20_27=_F(TOUT='OUI’) and then only using the quad sides of the HEXA27 and the triangular sides of the PENTA15 elements: -Will this be ok? –Or will the nonconformity between then voluminal HEXA27(with mid side node) and the PENTA15(without midside node) reduce the accuracy of the stresses and the deformations?

2 -For a HEXA20_27=_F(TOUT='OUI’) + PENTA15_18=_F(TOUT='OUI’) mesh a way to attach the QUAD9 side to the PENTA18 could be to merge the mid side nodes manually (for example by importing them into Salome + merge + export). –Would this be good way to solve this issue if you want to be able to use also the quad sides of the pentas? –Or is there another way? (The documentation says not “At present, mixed grids made up at the same time ofHEXA20 and of PENTA15 are not transformable by CREA_MAILLAGE”) –Still Would the presented “manual merge” idea work?

3 –For a mesh with only PENTA18 (created with the PENTA15_18 =_F(TOUT='OUI’) operation) will the QUAD9 sides perform as good in contact as if the underlying element was a HEXA27?

4 -Anyone want to recommend an automatic hex-mesher? -Are the Salome plugins DISTENE "MG-" algorithms good?

Thank you for your inputs!

BR/Micke

BR/Micke

It seem that I get much better results if I use ALGO_CONT='PENALISATION’ combined with ALGO_FROT='PENALISATION’. Maybe one should not mix ALGO_CONT=STANDRARD’ and ALGO_FROT='PENALISATION’?.

So first I then need to set a reasonable COEF_PENA_CONT. For DISCRETE formulation the documentation u2.04.04 says:

“One generally chooses E_N by successive tests: • first of all one will start by taking a value equalizes with 10 times the largest Young modulus of the structure multiplied by a length characteristic of this one; “. For CONTINUE formulation I can not find any guide in the documentation. Is it reasonable to use a value similar to E_N?

So for example would it be reasonable, for a simulation with modulus of elasticity 210e3MPa and with a contact diameter of 100mm, to use:

COEF_PENA_CONT=E_N=10*210e3*100=210e6?

Here: code-aster.org/forum2/viewtopic.php?id=24855 a much lower value is suggested: COEF_PENA_CONT=210e3/100=210e1

Which of these values are reasonable to start with? 10*E*size=210e6 or E/100=210e1???

/Micke

Hi,

As I mentioned above the ALGO_FROT='PENALISATION’ algorithm seem attractive since it stable and relatively fast converges to a solution.

I did a study of how to adjust the COEF_PENA_FROT parameter so that the friction forces would be accurately transferred. See attached pages. However with the simulations I did I found no way to adjust the parameter that would accurately describe the load path in this case. In this study HEXA27 elements are used.

-Is it due to over estimated slip that ALGO_FROT='PENALISATION’ can not accurately describe the load path?

-Do you have any tip how to improve the contact definition (see last page)?

BR/Micke

The files/Micke

**mihe**- Replies: 2

Hi, I ran the same contact analysis with Salome Meca 2019 and 2021. See attached picture and files

-Why are the SM2021 contact results with HEXA27 elements so spotted?

Some other points:

-While debugging mistakes in the .comm file I notice that very few errors are reported to the .mess file with SM2021.

-With SM2021, concepts are not presented by their names but by some id number. For example in the .resu file the RESU concept R1 = STAT_NON_LINE.... is denoted 00000011.

-SM2021 include CA version 15.4. On the down load page only CA 14.4 can be downloaded (stable version). -Is it possible to down load also CA 15.4? -where?

-Is anybody else experiencing these points with SM2021?

BR/Micke

Check also

"salome_meca-lgpl-2021.0.0-1-20210811-scibian-9.sif" under installation. Should be

"salome_meca-lgpl-2021.0.0-0-20210601-scibian-9.sif" I think.

BR/Micke

I have downloaded salome_meca-lgpl-2021.0.0-0-20210601-scibian-9.sif a couple of times. I get md5sum

c34331b7c3161021cb20731cd9a16b16 which is different from on the code-aster.org download page

65e153eaf43edcd3b671d41194936f53.

-Is my file corrupt? -is the checksum on the download page wrong? -someone else experience the same?

BR/Micke

Thank you for inputs Claws and Irvise. I will try your recommendations with Hexahedron (i,j,k) Irvise.

-It would be interesting to have a comment about plugins DISTENE "MG-" algorithms? since they would be integrated into salome. -Anyone have experience from them? -good? -affordable?

BR/Micke

The Picture/Micke

After more testing it seems that Using, ALGO_FROT='PENALISATION', solves this problem good. You just need to verify a reasonable value of COEF_PENA_FROT to use.

Document U2.04.04 says: "For studies where adherence is dominating, one will support values of COEF_FROT lower than the value by default(100) while for cases where the slip is dominating, one will choose higher values." -Does this mean that convergens will be faster by doing this? -Or that the accuracy of the calculated slip will be better? -Both? Is the same valid also for COEF_PENA_FROT?

When testing this out I found a interesting/odd result. Even if I force two surfaces to slide relative to each other CA says that some nodes are sticking. See attached case with a box sliding on a plane from instant t=2.0 to t=3.0.

-CA says some nodes are sticking (RTAX, RTAY, RTAZ)!=(0,0,0). See attached picture -Why?

-The slave nodes are on the box -should not the stick/slip efforts be in the other direction?

BR/Micke

**mihe**- Replies: 4

Hi, What algorithm are you using to create hexa mesh on 3D CAD models?

My experience is only from "Extrusion 3D". I then use 1D algorithm: Local length, 2D(submesh) algorithm Netgen + "Quad-dominated" and 3D algorithm "Extrusion 3D". These algorithms work ok for some shapes but essentially the geometry must be divided up in parts each being 2D and then extruded from that.

-How do you proceed to overcome this for more complex shapes? -What algorithm are you using?

-Anybody using the plugins DISTENE "MG-" algorithms? -Are they good? -Easy buy and install?

BR/Micke