First of all, I want to thank you for this forum and for PrePoMax itself
I have been working with this program for six months and have not had any major issues. However, after updating the geometry of this shaft, some faces are missing. I checked the STEP part in Hypermill, and it looked completely fine. So, I think the problem lies in PrePoMax’s import. I experienced a similar bug with another part that also had missing surfaces after making small changes to the geometry.
Abaqus imports it without errors and claims the geometry is correct but fails to mesh it. FreeCAD shows some errors at the end which PrePoMax displayed with missing surfaces:
I have the same errors with PrePoMax, but you can easily import the step (without errors) and mesh in Salome with a simple Netgen algorithm. I have attached the Salome model and the resulting mesh in UNV format that you can import in Prepomax to work.
Thanks for your replies! So that means that my design is problematic, or that Siemens NX is not exporting it correctly. I’ll try to repair the geometry in NX and keep you posted.
@SergioP1975, can you tell me which version of Salome you are using? Since PrePoMax uses Netgen as a geometry importer, I am wondering why PrePoMax does not show the geometry, even if it is broken or problematic.
In SolidWorks, no problems are detected on import, but visualisation has some issues.
CAD data for FEA should always be checked for quality (mouse-click is not a good practice).
I first analyze each rigid format (stp, igs, vda, …) with our basic CAD program and correct it if necessary (as in this case).
In this case, I only performed a test mesh, without quality control. Before performing the mesh for analysis, the geometry can also be simplified (this avoids some of the problems from above).
Me too. Fortunately, Abaqus has surprisingly powerful tools for that such as auto-repair by tightening gaps and recomputing, virtual topology (ignoring selected edges/faces during meshing - shown below, allows Abaqus to mesh this) and replacing faces (PrePoMax has OCC equivalent of that and it’s pretty good too). You can usually clean-up even the worst CAD models from your customers.
I was able to get an usable mesh in Salome, the trick is creating a first order tets, and then switch to second order with the middle node in the middle of the element edge (and not in CAD surface), to avoid the non jacobian errors. It´s incredible that Salome can´t do that directly! Expor the mesh as UNV
Then in Preomax, import the mesh, delete the surface part and scale the solid part propperly if is needed. I have create two faces sets in the knurling zones, one fixed, and the other attached to a reference point to apply a moment.
Now, if one knurled zone is “fixed”, and the other attached to a rigid body, that means that the small radius and details in the knurling could be avoided/simplified, because they became rigid!! It´s all depend on the bc and results needed.
A last point, how could we show the model in (scaled) deformated state, but twisted and not increasing the movil side diameter? This is something that happens with all postprocessors when a torsion is applied.
Is there no option such as “Second order linear” (called “Midside nodes on geometry” in PrePoMax) in Salome ? This should automatically generate second order elements by linear interpolation. FreeCAD has it for both Gmsh and Netgen and it’s indeed the best way to avoid negative jacobians: https://wiki.freecad.org/FEM_Geometry_Preparation_and_Meshing#Negative_Jacobians
I have checked and there is no second order linear elements option in Salome (at least for Netgen meshing), the only way is create the mesh as first order and after change it to second order, and there you have an option to select if the nodes lies in geometry or midle element edge.}
About the scaled deformation, could it be that if we transform the displacement to a cylindrical coordinate system and the scaling would be related to the angular position would show then the part only twisted and not enlarged? What if that could be implemented as an option to the moment load, so the results are transformed directly?
Thank you for all the helpful contributions on this topic. I have now made the shaft shoulder in my model slightly smaller than the base circle diameter of the gearing, and everything is running smoothly again.
For me, however, this is more of a workaround, as the shoulder on the real shaft should have the same diameter as the base circle. This raises the question of how I can reproduce this in the design without creating these errors again.
I also want to suggest something. Please check your original CAD file created in NX for this error.
Try to disable the teeth of the shaft, to see, if the geometry can be exported and imported into PPM without any errors. (see picture below, after importing into abaqus CAE). The errors will change, when I scale the part.
If this is not the case, there might be some conversion errors due to round off and accuracy limits. The part is quite long in order of magnitude ~ 1e3 but some features are quite tiny, this might cause the error, when converting into *step. You could chop off the whole shaft and test again, if this might work, just importing the teeth.
Virtual topology available in Abaqus and mentioned in my previous post allows you to just ignore some edges (so that the mesh doesn’t have to conform to them), and this resolves the issue when there are such narrow gaps between the edges, forming tiny face regions. It would be awesome to have such a feature in Salome, Gmsh, Netge,n or possibly just directly in PrePoMax. I just wonder if and how it could be implemented.
I looked into this before. In Netgen, the virtual topology could be created by meshing the underlying STL mesh of the CAD file. There, the current algorithm enforces edges from PrePoMax to Netgen, and some edges can easily be skipped to merge surfaces. But other problems might pop-up due to STL meshing.
Gmsh has the ability to compound/merge surfaces and edges/curves, which can be used as virtual topology. But I did not test these possibilities and do not know how well they work.
In the current example, the first problem is visualisation in PrePoMax, which fails.
