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

You are not logged in.

- Topics: Active | Unanswered

**MrSeb2000****Member**- From: Canada
- Registered: 2017-10-10
- Posts: 17

Hi All,

When conducting dynamic analyses on a suspension bridge modeled using POU_D_T and CABLE elements with GROT_GDEP option, I have noticed that the average response is drifting for long dynamic simulations (for a zero mean loading). I apply an initial rotation to the deck (around the bridge axis) and a harmonic loading (zero mean) in the Z direction for 1800 s. See the attached figure for the suspension bridge. So far, I have applied relatively small loads on the bridge (amplitude of 10 kN/m). The effect of large displacements and rotations should be small for such small loads, and such drifting should not occur.

Therefore, I decided to investigate the behavior of all POU_* elements with GROT_GDEP for a simpler system, which is a pendulum released from an initial angle of 60° with respect to the vertical and subjected to gravity only (damping is neglected). The period for the pendulum is about 0.6 s. The pendulum is a bar with a length of 0.5 m (see the attached archive file). This example comes from:

Bathe, K.-J. and Baig, M. M. I. (2005) On a composite implicit time integration procedure for nonlinear dynamics, Computers and Structures, 83:2513-2524

For all simulations of the pendulum, the HHT integration scheme (alpha=-0.1) with a time step of 0.002 s was used for the 10 s simulations. GROT_GDEP was used. All the simulations were run on Kubuntu 18.04 with Code_Aster 13.6smeca. Here is the list of cases considered:

Pendulum modeled as 20 beam elements (POU_D_E, POU_D_T, POU_D_TG, POU_D_EM or POU_D_TGM): Drift is observed for the vertical motion (y direction)

Pendulum modeled as 20 POU_D_T_GD elements: Simulation does not converge

Pendulum modeled as 1 CABLE element: No drift of the vertical displacement over time

Pendulum modeled as 40 C_PLAN elements: No drift of the vertical displacement over time

So, all beam elements show this drifting behavior except POU_D_T_GD, for which it was not possible to have convergence. Reducing the time step to 0.0002 reduces the drift, but after sufficient time, the drift can still be important. I don't know why the POU_D_T_GD element does not converge, but my experience with this element tells me that it is difficult to converge. Since the CABLE and C_PLAN models give good results, I would guess the drifting is caused by the modeling of large rotations for beam elements. All meshes, comm files and figures for the different cases can be found in the archive file.

In R3.08.09 (POU_G_TGM with GROT_GDEP), it is mentioned that the updated Lagrangian approach used is valid for moderate rotations since the matrix R is developed to the second order (this leads to a correction matrix because of the rotations). According to R3.08.01, other beam elements don't have this correction matrix. I verified the source code for the different beam elements and it seems to be the case. However, the drifting behavior is not affected by the correction matrix because I obtained the same results for POU_D_TGM and POU_D_T for example. The test case ZZZZ364 mentions that significant errors are obtained for POU_D_EM and POU_D_TGM elements for large rotation analysis.

What could I do not to have this drifting behavior when using POU_* elements? Is it a limitation in Code_Aster or a bug?

Thank you in advance for your help,

Sébastien

Offline

**AsterO'dactyle****Administrator**- Registered: 2007-11-29
- Posts: 312

Hello,

You're right and it's well known that beams in code_aster are not robust (POU_D_T_GD) or not correct (POU_D_T_* with GROT_GDEP).

A work is underway on the subject and we hope to have good elements for these situations.

Hopefully, in 2019...

Code_Asterの開発者

Offline

**MrSeb2000****Member**- From: Canada
- Registered: 2017-10-10
- Posts: 17

Hello AsterO'dactyle,

Thank you for the response. This is good to know that work is underway for improving the POU_D* elements when considering large displacements and rotations. Is this work available in the development version of Code_Aster on Bitbucket?

Regards,

Sébastien

Offline

**jlf****Member**- Registered: 2007-11-22
- Posts: 240

Hello,

To complete the answer of AsterO'dactyle, a part of the error with GROT_GDEP come from GROT and the dynamic scheme. The dynamic scheme (NEWMARK or HHT) is obtain by a limit development (R5.05.05, §3.1). For GROT we need to take into account that there are 'larges rotations' and compute the displacement, speed and acceleration in the actualized coordinates system (R5.03.40, Annexe 3).

In fact each element should compute the precedent values of these own rotations, speed of rotations, acceleration of rotations in the actualized coordinates system. And is not the case for all the beam element.

When you use an element with no DoF of rotation is ok, like C_PLAN, CABLE.

And like say AsterO'dactyle

A work is underway on the subject and we hope to have good elements for these situations.

Hopefully, in 2019

JLF

Offline

**MrSeb2000****Member**- From: Canada
- Registered: 2017-10-10
- Posts: 17

Thank you JLF for providing more information.

Regards,

Sébastien

Offline