On a simple plate element model, the frequency of the first mode increases drastically when reducing the mesh size. The results with Simulation Mechanical 2014 SP1 are as follows:
Mode Mesh Size
0.5 0.1 0.05 0.03 mm
1 12.7 266 778 1990 Hz
2 17.6 18.2 18.3 18.3 kHz
3 35.9 36.7 36.9 36.9 kHz
4 37.2 38.4 38.6 38.7 kHz
5 39.4 41.0 41.3 41.4 kHz
I suspect a software bug. Any suggestions?
Hello Wolfgang,
I'm sorry to learn that you are experiencing unusual first mode results while using a finer mesh. Perhaps this issue could be addressed more directly by creating a case from within the Autodesk Subscription Center? That way your model can be collected and we can discuss the details more clearly.
Hi Pat,
Since my initial post, I did the following:
- analysed the model with a different FEA software and found that it did not result in the low frequency mode, but agrees with modes at 18,36,38 kHz
- analysed the Simulation Mechanical model with different plate element formulations and found that the low frequency mode occurs only for the Veubeke formulation, using any of the others resulted in only the modes at higher frequencies.
I'm now sure that there is a bug. I will send you the model. Please try to replicate my findingas and confirm.
Hello Wolfgang,
You and I had a conversation about this issue, so my post is for the benefit of others.
For the plate model you provided, the first reported mode shape and frequency was not correct and in fact, the second mode shape and frequency reflected the actually first mode shape and frequency. The incorrect mode shape is obvious in its convoluted and inconsistent display. Using the other solver returns the error that the matrix was not positive or definite. You and I found the following work-arounds for this limitation:
Either of these changes produce believable results for the first mode. It seems the original problem is related to the large number of constrained plate element nodes for which the translational degrees of freedom are constrained, but the rotational degrees of freedom remain unconstrained. The Reduced Shear element formulation works because this formulation has a reduced order. The reason the sparse solver provided an incorrect result compared to the sub-space iteration solver is because the sparse solver "could" provide a solution whereas the subspace iteration solver could not. So, with the added ability to produce a result that the subspace solver solver could not also requires that operator must assess the results to ensure validity... as as you did.
Nonetheless, the details of this issue have been forwarded to development for further review and the known work-arounds are posted here for completeness.