Model solid cylinder with brick (hexahedron) elements rather than tet elements?

dculp

I have a solid cylinder for which I want to run a modal analysis. I have analyzed this with Mecway's built-in mesher which generates tet elements. I want to compare this to an analysis that I had previously run with Autodesk using mainly brick elements. I have results from the Autodesk analysis but no longer have access to that software. Because the Autodesk results are somewhat different than the Mecway results, I want to see if this might be due to differing element types.
-- Can Mecway analyze with brick elements?
-- Is there a way to force Mecway to generate brick elements? If not, is there an external mesher that will do this? (I looked at gmsh. It seemed too complicated but I wouldn't rule it out if it's the only option.)

Thanks,
Don C.

Victor

If it's a simple enough geometry (just a cylinder?) then you can make a quad dominant shell mesh then extrude (Mesh tools -> Extrude) to convert to hex20 dominant solids.

Have you tried mesh refinement on the tet mesh? All solid element types should converge to the same solution on refinement.

dculp

Victor --

I'm interested in the axial mode at 20 kHz and the adjacent slightly higher bending mode to see their interactions. When resonances are closely spaced, small differences in the frequency separations can have large effects on the interactions.

As you suggested, I built a brick model by extruding a quad shell mesh.

The frequency results (axial, then bending; for interest the first and second torsional modes are in brackets) --

Original Autodesk brick model (~2132 elements) -- 19999.2, 20171.2

Mecway tets model H1001a (3823 elements, attached) -- 20012.4, 20346.7 [12356.8, 24716.6]
Mecway tets model H1002a refined (21158 elements) -- 20012.4, 20343.1 [12356.2, 24712.7]

Mecway brick model H1010f (3472 elements, attached) -- 20019.1, 20132.4 [12356.1, 24712.2]
Mecway brick model H1011f refined (21056 elements) -- 20019.1, 20132.1 [12356.1, 24712.3]

The refinement shows that both the Mecway tets models and the Mecway brick models have converged. However, the tet and brick bending modes don't agree. Comparing the refined Mecway models, the bending mode of the tets model (20343.1) is 211 Hz higher than the brick model (20132.1). So the refined tet model and brick model don't converge to the same bending frequencies (same for the unrefined models).

The bending mode of the Mecway brick models agree reasonably with the original Autodesk brick model (about 40 Hz lower).

(The theoretical torsional frequencies are 12356.1 and 24712.3. These agree almost exactly with the FEA results for both tet and brick models.)

Conclusion -- For both tet and brick models, the axial frequencies and torsional frequencies agree. However, the tet bending frequencies are higher than the brick bending frequencies .

H1001a - axial mode



H1001a - bending mode



H1001a - first torsional mode



Mecway 18.0
Windows 10 Pro

Victor

The hex mesh is a slightly different diameter. I scaled it in X and Y by their ratio 1.0243277848911652 and now the 2nd bending mode is 20342.93 Hz compered to 20346.59 Hz for tet which is much better agreement.

dculp

Thanks for spotting the dimensional error in the Mecway brick models -- all models should have been 40 mm diameter. (The person who created the incorrect models has been severely reprimanded )

Still, I wonder about the Autodesk results. Although I can't access the original FEA model, I do have the step file from which it was created. This step file (40 mm diameter) was used to create the Mecway tets models. All Mecway material properties were taken from the Autodesk file.

As shown, the bending frequency of the Autodesk brick model (20171) is 176 Hz lower than the correct Mecway bending frequency (20347, unrefined). Although this difference may seem small, it can have a significant effect on modal interactions.

dculp

The Autodesk log file shows that element compatibility is not enforced. I seem to recall that this results in reduced element stiffness (correct me if wrong). If Mecway's tet elements enforce compatibility, could this be why the Autodesk brick model has a lower bending frequency than the Mecway tet models?

Other possible explanations?

Victor

I don't know what element compatibility means there or whether it would improve or worsen the frequencies.

I'm leaning towards something being wrong with the Autodesk model, material properties, or dimension since there are very consistent results with diverse settings in Mecway:
20343 Hz hex unrefined (15349 nodes) internal solver
20343 Hz hex refined (114065 nodes) internal solver
20343 Hz hex unrefined (15349 nodes) CCX solver
20343 Hz hex refined (114065 nodes) CCX solver
20346/7 tet unrefined (6861 nodes) internal solver
20347 Hz tet unrefined (6861 nodes) CCX solver
20343 Hz tet refined (47605 nodes) CCX solver

disla

.

dculp

Here is some info from the Autodesk model files --

H1001a__Autodesk_partial_model_image



H1001a__Autodesk_material_properties. These values, when converted, agree with Mecway. (Mecway doesn't explicitly state the shear modulus.)



H1001a__Autodesk_element_properties



H1001a__Autodesk_mesh_statistics. Autodesk first generates a surface mesh and from there generates the solid mesh elements.



H1001a__Autodesk_nodes_dimension_confirmation. The radius (X) ranges from -20 mm to +20 mm (i.e., diameter = 40 mm). The length is 126.54 mm.



H1001a__Autodesk_frequencies. As discussed, the bending mode frequencies at 20171 are low compared to Mecway.



The only anomaly that I could find is that mesh statistics show a volume of 157469.5 mm^3. However, for a 40 mm diameter x 126.54 mm long cylinder, the volume should be 159015 mm^3 (a difference of 1%).

I also ran the same models in PrePoMax --
--> Tets -- parabolic C3D10 elements (the only tets available)
--> Bricks -- parabolic hex C3D20 or C3D20R + parabolic wedge C3D15
All PrePoMax FEA gave the same results as Mecway with either tets or bricks. (The PrePoMax FEA were analyzed with the Spooles solver.)

I did find that using nonquadratic elements increases the bending frequencies (attached models) --
--> Tets (H1003a.liml) -- 21300 (+953)
--> Bricks (H1020e.liml) -- 20532 (+186)

Conclusion -- The difference in bending frequencies between Mecway/PrePoMax and Autodesk is unresolved. However, I suspect it may be due to differing element formulations. At this point I guess I'll have to accept the Mecway/PrePoMax results unless there are other suggestions.

Victor

I wonder if it is that compatibility not enforced option. From a quick search, it looks like that causes strains to be compatible between adjacent elements at the expense of displacements, so gaps and intersections can form. That's the opposite of what Mecway and CCX do - allowing strains to be discontinuous instead. I imagine that a refined mesh in Autodesk would agree with Mecway. Different element formulations won't change the solution after refinement unless one of them is wrong or modelling different physics.

1% difference in volume is about what you get without the midside nodes following the cylindrical surface, but that still doesn't cause such a big difference in frequency.

disla

Hi dculp,

I have found the rod exact modes formula for the free-free BC.
I have run all the 6 tests comparing 1st and 2nd bending and 1st torsional modes and biggest error is 0.04%. You can find the exact solution and test details at :

https://www.mdpi.com/2571-631X/2/1/10


Test Transverse Mode (Hz) Torsional Mode (Hz)
1st 2nd
Exact Solution MECWAY/CCX Error (%) Exact Solution MECWAY/CCX Error (%) Exact Solution MECWAY/CCX Error (%)
1 2,103.08 2,103.12 0.00% 4,914.20 4,914.43 0.00% 3,626.66 3,626.61 0.00%
2 2,100.39 2,100.51 -0.01% 4,896.90 4,897.78 -0.02% 3,546.94 3,546.90 0.00%
3 2,097.75 2,097.92 -0.01% 4,879.97 4,881.19 -0.03% 3,472.26 3,472.22 0.00%
4 1,326.55 1,326.84 -0.02% 3,085.94 3,087.13 -0.04% 2,195.75 2,196.02 -0.01%
5 1,876.35 1,876.41 0.00% 4,364.93 4,365.87 -0.02% 3,105.79 3,105.64 0.00%
6 2,297.92 2,298.16 -0.01% 5,345.62 5,347.08 -0.03% 3,803.59 3,803.62 0.00%