structure frequency responses under vibration forces

[alexbrown]

I am trying to calculate structure frequency responses under vibration forces (e.g. acceleration etc), but i can only find examples for eigen value analysis.

Can elmer calcualte the dynamic frequency responses as well, e.g. the dynamic responses on a point A when the vibration forces is applied on point B?

[mika]

The command "Harmonic Analysis = True" should provide a way to obtain the response in the case of a simple-harmonic forced vibration. This implies that the solution is sought as complex-valued. On the other hand I believe the modal superposition based on eigenmodes hasn't been implemented as a ready procedure.

-- Mika

[alexbrown]

The command "Harmonic Analysis = True" should provide a way to obtain the response in the case of a simple-harmonic forced vibration. This implies that the solution is sought as complex-valued. On the other hand I believe the modal superposition based on eigenmodes hasn't been implemented as a ready procedure.

-- Mika

Thanks, Mika! Do you think it will be difficult to add modal superposition based on eigenmodes in elmer? As you know, this maybe a quite useful function for structure dynamic analysis.

Further more, is that possible to use Shellsolver for harmonic Analysis?

[mika]

It should be possible to make harmonic analysis with the shell solver, but you should now use a different command to activate the harmonic analysis. The solver section associated with the shell model should have the command "Harmonic Mode = True". Having two different keywords (Harmonic Analysis/Harmonic Mode) to activate the analyses of the same kind is not perfect, but to some extent different pieces of code are executed depending on whether "Harmonic Analysis" or "Harmonic Mode" is used for the activation. A limitation is that the shell solver with "Harmonic Mode = True" cannot yet assemble a complex-valued load (only a real-valued RHS can be specified). If the real component of the shell variable is specified in the sif file for example as "U 1 = Real ...", it should be possible to give the corresponding imaginary component as "U 1 Im = Real ...", so there is an augmentation with the string "Im".

I believe coding the modal superposition method should be a rather straightforward task, but some dedicated time would nevertheless needed to make the implementation.

-- Mika

[alexbrown]

Hi Mika, many thanks for the kind instruction. i followed your instruction and using harmonic mode = true for analysis, the results can be calculated(with U 3 Load = Real and U3 Load Im = Real), but in the results at all frequencies, the imag part of u and dnu is all zero, is that correct?

Further more, i used the shell solver for the eigen value analysis of a plate and a box composed of plate. The eigen value for single plate is correct, but the eigen value of a box can not get consisent results with other commercial software. Did you tried using shell solver for composed structure of plate before? I used target nodes keywords for defining the displacement boundary condition, is this maybe the reason?

It should be possible to make harmonic analysis with the shell solver, but you should now use a different command to activate the harmonic analysis. The solver section associated with the shell model should have the command "Harmonic Mode = True". Having two different keywords (Harmonic Analysis/Harmonic Mode) to activate the analyses of the same kind is not perfect, but to some extent different pieces of code are executed depending on whether "Harmonic Analysis" or "Harmonic Mode" is used for the activation. A limitation is that the shell solver with "Harmonic Mode = True" cannot yet assemble a complex-valued load (only a real-valued RHS can be specified). If the real component of the shell variable is specified in the sif file for example as "U 1 = Real ...", it should be possible to give the corresponding imaginary component as "U 1 Im = Real ...", so there is an augmentation with the string "Im".

I believe coding the modal superposition method should be a rather straightforward task, but some dedicated time would nevertheless needed to make the implementation.

-- Mika

[mika]

i followed your instruction and using harmonic mode = true for analysis, the results can be calculated(with U 3 Load = Real and U3 Load Im = Real), but in the results at all frequencies, the imag part of u and dnu is all zero, is that correct?

While it's logical to think that nodal loads could be specified for the complex components activated with the command "Harmonic Mode = True", the general utilities of Elmer have not been updated to handle the complex parts correctly. So in this case any attempt to specify nodal loads for the complex components is ignored. I'll try to update the shell solver so that a complex-valued load would be supported.

Did you tried using shell solver for composed structure of plate before?

In all verification cases done with the shell solver the geometry has been some basic shell without discontinuities. Might discrepancies be associated with non-smooth corners? Does the other software use some special constraints at the joints?

I used target nodes keywords for defining the displacement boundary condition, is this maybe the reason?

I think this shouldn't be a problem.

-- Mika

[alexbrown]

Hi Mika, I used commercial software with same constraints at corners(pined four corners of a box). Elmer is using same boundary conditions(u1=0 u2=0 u3=0).

Could you please kindly help to quick check whether this is caused by Elmer discontinuity treatment at corners? The eigen value analysis seems to be not correct too compared with other software.

i followed your instruction and using harmonic mode = true for analysis, the results can be calculated(with U 3 Load = Real and U3 Load Im = Real), but in the results at all frequencies, the imag part of u and dnu is all zero, is that correct?

While it's logical to think that nodal loads could be specified for the complex components activated with the command "Harmonic Mode = True", the general utilities of Elmer have not been updated to handle the complex parts correctly. So in this case any attempt to specify nodal loads for the complex components is ignored. I'll try to update the shell solver so that a complex-valued load would be supported.

Did you tried using shell solver for composed structure of plate before?

In all verification cases done with the shell solver the geometry has been some basic shell without discontinuities. Might discrepancies be associated with non-smooth corners? Does the other software use some special constraints at the joints?

I used target nodes keywords for defining the displacement boundary condition, is this maybe the reason?

I think this shouldn't be a problem.

-- Mika

[mika]

In the first place the development of the shell solver started by assuming a smooth shell so that the director data at the nodes would be unique. Now, when the shell consists of patches with a couple of patches meeting at right angles, I see possible troubles or at least sources of possible inaccuracies due to a jump of the director field at a kink. I'm not sure whether this could explain your troubles. I have not checked eigenanalysis results in such a case yet.

Giving averaged director data near places where patches meet at right angles might help, but unfortunately this is likely to be cumbersome. Since the shell solver tries to fit a curved surface using the director data in order to calculate surface curvatures, a very rough orientation change within one element may also give a bad fit. So all simple approaches may be subject to inaccuracies.

Mathematically I see a jump in the director data problematic by the following reason. In the Elmer implementation the DOFs related to the bending and the stretch of the director are defined in terms of the directional derivative of the displacement, so that three DOFs define uniquely the vector v = (grad u)d at the nodes, with (grad u) being the displacement gradient and the director. If the director is defined only elementwise, two elements sharing a node calculate a different vector v (the directional derivatives in different directions) and this makes me to think that the DOFs of the adjacent elements are not compatible any more, although Elmer is expected to make the system assembly without any warnings.

-- Mika

[alexbrown]

Hi Mika, many thanks for the kind help. As you may understand, two shells meet at right angles may be common for many cases.

Do you think there is alternative solvers in Elmer that can solve these kind of thin plate boxes? Will you consider to update the shell solver?

In the first place the development of the shell solver started by assuming a smooth shell so that the director data at the nodes would be unique. Now, when the shell consists of patches with a couple of patches meeting at right angles, I see possible troubles or at least sources of possible inaccuracies due to a jump of the director field at a kink. I'm not sure whether this could explain your troubles. I have not checked eigenanalysis results in such a case yet.

Giving averaged director data near places where patches meet at right angles might help, but unfortunately this is likely to be cumbersome. Since the shell solver tries to fit a curved surface using the director data in order to calculate surface curvatures, a very rough orientation change within one element may also give a bad fit. So all simple approaches may be subject to inaccuracies.

Mathematically I see a jump in the director data problematic by the following reason. In the Elmer implementation the DOFs related to the bending and the stretch of the director are defined in terms of the directional derivative of the displacement, so that three DOFs define uniquely the vector v = (grad u)d at the nodes, with (grad u) being the displacement gradient and the director. If the director is defined only elementwise, two elements sharing a node calculate a different vector v (the directional derivatives in different directions) and this makes me to think that the DOFs of the adjacent elements are not compatible any more, although Elmer is expected to make the system assembly without any warnings.

-- Mika

[mika]

There exists an old and undocumented facet shell solver (FacetShellSolve) which utilizes drilling DOFs. While it's known that the facet shell elements may generally be unreliable (no convergence to solutions which a proper shell theory predicts, which gave a motivation to write a new shell solver), in the case of geometries consisting of just planar patches good results might however be possible (convergence failure needs a curved mid-surface).

I checked the first eigenvalues of a beam which has an L-shaped cross section and which is fixed at one end by using a facet shell model

facet-L.png (17.83 KiB) Viewed 4594 times

and a 3D solid model

solid-L.png (16.86 KiB) Viewed 4594 times

The solid model gives

EigenSolve: Computed 10 Eigen Values
EigenSolve: --------------------------------
EigenSolve: 1: 1.319919E+03 0.000000E+00
EigenSolve: 2: 4.496784E+03 0.000000E+00
EigenSolve: 3: 5.081996E+04 0.000000E+00
EigenSolve: 4: 5.499638E+04 0.000000E+00
EigenSolve: 5: 1.509114E+05 0.000000E+00
EigenSolve: 6: 3.854250E+05 0.000000E+00
EigenSolve: 7: 5.035877E+05 0.000000E+00
EigenSolve: 8: 8.492267E+05 0.000000E+00
EigenSolve: 9: 1.406722E+06 0.000000E+00
EigenSolve: 10: 1.531419E+06 0.000000E+00
EigenSolve: --------------------------------

while the facet shell solver outputs

EigenSolve: Computed 10 Eigen Values
EigenSolve: --------------------------------
EigenSolve: 1: 1.216743E+03 0.000000E+00
EigenSolve: 2: 4.464833E+03 0.000000E+00
EigenSolve: 3: 4.679074E+04 0.000000E+00
EigenSolve: 4: 5.240912E+04 0.000000E+00
EigenSolve: 5: 1.466158E+05 0.000000E+00
EigenSolve: 6: 3.541928E+05 0.000000E+00
EigenSolve: 7: 4.769901E+05 0.000000E+00
EigenSolve: 8: 8.113645E+05 0.000000E+00
EigenSolve: 9: 1.278976E+06 0.000000E+00
EigenSolve: 10: 1.411605E+06 0.000000E+00
EigenSolve: --------------------------------

There seems to be quite good agreement of the eigenvalues, so perhaps you could try a facet model for a box. For an example case in the tests directory see the test FacetShell2.

-- Mika