Free-Free Beam Eigenvalue Test

[getty]

The template for this test was the command line tutorial on ElasticEigenValues. I did the mesh myself in gmsh, converted it with ElmerGrid to the ElmerSolver format, and then ran ElmerSolver and used tee to copy the solver output to a file.
I have attached three files:
1. The gmsh geo file
2. The Elmer sif file (BCs have been commented out so the beam is free-free)
3. The solver log file

I am confused by the results of this. The natural frequencies in the log file do not make sense when compared to their respective vtu output files. The first six frequencies are near zero, which is to be expected with rigid body modes in an unconstrained system. However, when viewing the generated vtu files in Paraview, they stop looking like rigid body modes past mode 4. In fact, mode 6 is the 1st bending in the Z direction (Y in Paraview), which should not have a natural frequency of approximately 0. Is this some sort of error in Elmer or have I somehow made a mistake?

When I comment out the boundary conditions in the original tutorial sif file, I get back reasonable data for the rigid body modes. All six seem fine and the first bending mode shows up as expected for mode 7, which leads me to believe an error in my workflow is the more likely cause, but I do not understand what kind of error could lead to actual modes showing up in the vtu files for rigid body modes.

[kevinarden]

Two comments
1. Paraview counts starting at zero, Elmer Counts starting at 1
So in Paraview mode 6 is Elmer mode 7
2. in your geo you do not name the volume, by default gmsh only writes out named items
Physical Volume("beam", 33) = {1};
So unless you took other action your mesh is just the boundary elements not the beam
check your mesh header file

[getty]

Kevin, thank you for the feedback. Replies to your items:
1. In my case the first vtu's suffix is 0001, so Paraview so mode 6 does seem to be mode 6. Also mode 5 is another 1st bending, so even if there is an indexing issue, 5 most definitely should be a rigid body mode.
2. I added the physical volume to the geo file, and tried to change the body id in the sif to 33 to respect this, that produced an error. Leaving it at 1 it ran, but I got the same output as before. How do I resolve this? Additionally, why is there no mesh.names file being generated by ElmerGrid like there is from the FDNEUT file conversion in the example files?

[kevinarden]

I receive a mesh.name file, the body is 33 unless you use autoclean which renumbers everything
ElmerGUI automatically uses autoclean if you open a msh file from GUI

The suffix of the vtu file is not related to the the index number in paraview, you can open the vtu files in paraview one at a time
if you open *.0001 it is eigen value 0

If you open *.0007 by itself it is eigen value 0

if you open the whole group file *.0001 is eigen value 0, and eigen value 6 in paraview is 7 in Elmer

[raback]

Hi

Just a note on something that could be confusing: If ResultOutputSolver (the one writing vtu files) is given the keywords "Eigen Analysis = Logical True" the numbering will reflect eigenvalues. Otherwise it will reflect timesteps (or steady state iteration steps) and specific naming scheme is used for eigenmodes. The reason for this is that a simulation could be both at the same time in some peculiar setup.

-Peter

[getty]

Kevin, I saved the .msh out of the .geo, and then ran ElmerGrid 14 2 mesh.msh. This created the mesh folder, but no mesh.name file was in it so I'm not sure what went wrong. I didn't autoclean, and I did add the physical volume line to the geo file through the gmsh gui, which resulted in the same id of 33. Does this mean that the sif should reference body 33 instead of 1? Does doing so require the mesh.name file to be in place?

I think what Peter has said confirms my understanding that the Paraview suffixes do correspond to the mode number, as both start at 1 and end at 15. If I've misunderstood anything please let me know.

[kevinarden]

without the autoclean the body number will stay in this case 33, and my ElmerGrid produces a mesh.name file that shows that. What version of ElmerGrid do you have installed? what is its compile date?

I agree that the suffix name of the file agrees with the eigenmode that is in that file but if you read any one of those files into paraview it will be 0.
If you select any group of them, in paraview the first one will be zero, second one 1, and so forth.

For example if I expand the group and select individual files

files.png

(605.02 KiB) Not downloaded yet

then in paraview I get a dataset for each file, but each one is 0 on the index

indiv.png (70.46 KiB) Viewed 329 times

but if I just open the group I get one data set and mode 1 is index 0 and mode 7 is index 6
does not matter what the file name is

group.png (52.32 KiB) Viewed 329 times

\

[getty]

I've managed to solve the problems that were present.
1. ElmerGrid was not generating a mesh.names file because the mesh.msh file coming out of gmsh did not contain the names. This information was lost by just selecting save mesh out of gmsh, export had to be used.
2. The body defaulting to an id of 33 caused issues. Elmer assumes that when there is a body id 33 that there are 33 bodies, which there are not. The solver fails:
LoadInputFile: Number of Bodies: 33
ERROR:: LoadInputFile: Entry missing for: Body 1
Changing the id to 1 manually in the .geo file fixes the issue.

The frequencies I'm getting are at least now reasonable given their mode shapes. However these values do not correlate well with the output of other finite element programs or theoretical calculations. Elmer is off by orders of magnitude from theoretical, and the other fea programs used are even further off. I am continuing to work on this issue to understand why they do not correlate well at all.

[kevinarden]

Correlation to theory will be dependent on mesh quality.
Element type is critical, first order (linear) triangles and tetrahedrons are unacceptable for ElasticSolver or StressSover.
2nd order is a must for those element times and a reasonably fine mesh.
Quads and hexa are much better, and 2nd order is still preferred. AS you increase the element quality, order, and fineness of the mesh the answers will start to converge on the theory.

[kevinarden]

results.png (10.97 KiB) Viewed 281 times

full set of results and problem description

comparison.pdf

(209.25 KiB) Downloaded 13 times

All files from study
https://github.com/mrkearden/free-free-beam