In analyzing some contact problems, I noticed a “strange” behavior of PrePoMax that I cannot understand. I have redone the calculation models several times, but I always get the same nonsensical values.
In the subfolder “02_Same analysis of FEAnalyst but step file created in Solidworks” I performed the exact same procedure, but using a step created by a friend in Solidworks (it should be the same as the one used by FEAnalyst).
The stresses are completely wrong with high peaks and the distribution is very irregular.
In the subfolder “03_Same analysis of FEAnalyst but step file created in Solidworks_different mesh” the same model created in Solidworks, but with the mesh changed from the automatic PrePoMax mesh to the Gmsh one.
There is an improvement in the pressure values, which are still wrong, but the pressure distribution is still very uneven.
In this case I have not found the cause, so I ask you what the problem might be.
Just swapping your geometry with mine (via Regenerate Model Using Other Files) eliminates the issue so it’s indeed a matter of the geometry. I haven’t found any visible differences but export from various CAD software and conversion to STEP sometimes leads to issues due to small inaccuracies.
The difference becomes clear when you take a closer look at the node distribution along the contact line. Apparently, the master and slave nodes in the original model coincidentally lie much more precisely on top of each other (in projected radial direction).
This is clearly visible when you compare the undeformed and deformed meshes:
In the third example (gmsh mesh), I would assume that the irregular element shapes also lead to inaccuracies. But here too, the nodes are more coincident in projected radial direction than in the second example.
Obviously, the same geometry created with different CAD software can produce different mesh results with the same mesh settings. This is how the triangulated geometries look like with element edges shown - but is this just visual or does it also influence the meshing? I think that Prepomax handles FreeCAD geometries better because both use the same kernel (OpenCascade).
There is a difference in the geometry. Using Query → Surface tool, one can see that the CAD kernel OpenCascade recognizes one geometry as a plane surface and the other as a BSplineSurface. That is why the graphical representation/triangulation is not the same. This is usually connected to the way how the surfaces were created and not only to the geometry kernel used.
Netgen/default mesher cannot create evenly distributed elements per edge, but in this case, Gmsh can. So, If you use Shell Gmsh mesher with some additional Mesh Refinements, you can get evenly distributed elements.
Removing the Poisson effect and friction exposes more clearly the effect of approximating a circular edge with an spline. The shape could almost be intuited.
Not sure if imported splines are quadratic polynomial or cubic but it definitely affects the stress distribution and displacement field.
An adjustment to fit a set of nodes to a circle could be useful in this sense. Or maybe even better to adjust the spline to convert it to a real circle.
I recommend using the same drawing method as for the smaller part. The smaller part is correctly recognized and the edges are transferred to .step file as circles (Query → Edge).
Thanks Matej and Asura. It’s being a nice finding. Let’s see if that’s related with the bolt holes peak stresses too and if they could also be drawn in such a way they are recognized as Circles.
Really nice discoveries, it is nice to be able to understand an instrument in more depth.
Anyway, I have re-done the analysis by fixing the modelling (You can find everything at the following link 04_Same analysis of FEAnalyst but step file created in Solidworks_recreated - OneDrive).
The distribution is much improved and is now uniform. However, I still get the same problems with high pressure values for the ‘basic’ mesh version.
In some cases, a compound can be used to get a coincident mesh with an option to split the mesh parts. Then a scaling of a single mesh part can be used to get interference.
Yes, that’s how I would do it too. Request for this: It would be useful to be able to select a local coordinate system, so that scaling in the radial direction would be possible even if the axis doesn’t coincide with one of the main coordinate systems.
