Over the last weeks I have been testing PrePoMax / CalculiX extensively and performed a benchmark study against Commercial FEM.
Regarding CPU scaling, I uploaded the full results to my YouTube channel, but in short:
For our tower benchmark, the sweet spot is 8 CPUs for LA, GNA, and GMNA.
At 8 CPUs, CalculiX / PrePoMax is roughly as fast as Commercial FEM for LA.
For GNA, Commercial FEM is about 2–3× faster.
For GMNA, Commercial FEM is about 4–6× faster (all comparisons at 8 CPUs).
In addition, I mapped 30 real, measured geometric imperfection fields onto a benchmark cylinder and compared GNA buckling loads between Commercial FEM and CalculiX / PrePoMax. The results are essentially identical, with a maximum deviation of about 5%, which is very encouraging—I actually expected larger differences.
I also tested full automation of the workflow (video uploaded). I created a reference input file in PrePoMax, modified it via Python, submitted it to the CalculiX solver, and post-processed the results with another script to extract the buckling loads. The whole workflow was very smooth and convenient—essentially the same as Commercial FEM, but free. I’m still a bit amazed at how well this works.
Over the next few days, I plan to test more complex stiffened shells and related cases.
I thought this information might be interesting for the PrePoMax community.
can Abaqus input files provided? computational times shown large discrepancy and it’s probably due to algorithm selection between Newton Raphson and Riks.
It’s actually Newton–Raphson vs. Newton–Raphson, not Riks vs. Newton.
The big gap in wall-time is mainly due to how much optimization is built into the commercial solver:
Commercial codes have heavily tuned linear solvers, parallelization and memory management, so for the same NR settings they typically run significantly faster.
In my benchmark, the commercial solver also uses native S8R shell elements. In CalculiX these quadratic shells are internally converted from solids, and that conversion plus the different implementation adds extra overhead.
So the discrepancy in CPU time is actually expected and not due to a different solution algorithm.
that’s clear, solid element in CalculiX vs Shell element in Abaqus cause of large discrepancy in computational times and of course is already well know.
*edited
personally, i’ll testing solid vs solid or shell vs shell (classical) of simple static case in CalculiX and Abaqus before going further to avoid misleading in conclusions.
Did you compare PaStiX and Pardiso matrix solvers of CalculiX first ? Did you submit the jobs using standaline CalculiX binary to avoid any additional load from the GUI ?
Abaqus is indeed highly optimized. For years, performance of the different solvers has been the key part of the development. Each new version brings significant performance improvements, recently with a special focus on linear dynamics procedures and eigensolvers. Abaqus also has very good algorithms to solve nonlinear problems efficiently - for example, to obtain accurate initial guess of the tangent stiffness matrix for the NR procedure.
since it’s related to solver and computational resources, it could be good to inform in CalculiX forum also.
p.s in case large deformation and plasticity, even computationally expensive due to expansion to solid, shell element S8/S8R in CalculiX can perform better than S8/S8R in Abaqus. Some report (links) shown graph below is less accurate; it had conclusion to carefully using shell element in Abaqus since assumption and limitation apply.
I only compared the Pardiso solver and submitted the jobs using the Python Script, which is shown in one of the videos on my YouTube Channel and also measures time to complete and so on.
