Closed stefano2734 closed 2 months ago
@stefano2734 Thanks for looking into this!
Hm, that's interesting. So Calculix should in fact produce eigenmode results closer to the rest of the solvers (Abaqus, Code Aster and Sesam all produce rather similar results).
I haven't looked at the input file example he provided, but I guess it should be easy enough to figure out if ADA is using some non-ideal element types for Calculix.
It would also be interesting to know which eigenvalue solver he was using. I am no expert in the different solvers for Calculix, but it might be interesting to know if the default conda forge calculix package is compiled with something else than ideal. (see the conda forge build.sh for the calculix compilation script for linux).
I am only days away from completing my work on converting Code Aster to MSVC. Once that's done, I will start looking into the issues you've raised and start tackling them :)
Thanks again for your efforts!
You can read the used inp-file as txt-file for better results for quad4 as txt in answer of issue: https://github.com/Dhondtguido/CalculiX/issues/87
it should be a difference to your inp-file and your run.
Hey @stefano2734, I have finished converting Code Aster, and I have looked into your comment.
I believe the differences in the results is simply due to the tests in ada-py are for shell elements currently using Reduced integration (S4R in Abaqus and Calculix). The example you have referred to is using full integration (S4).
I am starting to update the FEM tests in the branch https://github.com/Krande/adapy/tree/fix/fem-tester-update. There I'll update the test suite to include tests for both reduced AND full integration (which I will also specify in the result tables in the verification report).
Thanks again for looking into this! I'll close this issue when I merge https://github.com/Krande/adapy/tree/fix/fem-tester-update into main
Best Regards Kristoffer
Hey, I solved this in: https://github.com/Krande/adapy/pull/106
Now the table reflects that Calculix using reduced integration for QUAD elements is stiffer than QUAD elements using full integration. Also that when using full integration abaqus and calculix produce very similar results
Great, but I see in the table ccx tri with some weakness with great differences with more than 50%.
Calculix quad solved, but calculix tri 1st order something to do in parameters or calculix development. Abaqus, Sesame, Code Aster are here similar good.
My guess is that this might be a result of the different stiffness of the solid wedge element type (which calculix converts the tri-elements internally to).
I have double-checked the input files, and the results for Calculix "TRI" is using the intended "S3" element type. In Abaqus the S3/S3R elements are identical, so I have only reported "TRIR" ("S3R") for abaqus.
I see that you've asked the Calculix people if they could test TRI elements as well. Hopefully they'll double-check that our results are the same
Describe the bug A clear and concise description of what the bug is.
I see a great difference in actual Ada report by shell first order by Calculix for tri3 and quad4.
https://github.com/Dhondtguido/CalculiX/issues/87
great difference Ada report not seen by Calculix user in actual calculation by him with quad4
all ok at shell first order quad4. inp-file of this calculation is available.
tri3 is here a calculation also to check and now an open point.
To Reproduce Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context Add any other context about the problem here.