Krande / adapy

A python library for structural analysis and design
https://krande.github.io/adapy
GNU General Public License v3.0
96 stars 21 forks source link

Calculix file or run with error in shell first order #101

Closed stefano2734 closed 2 months ago

stefano2734 commented 4 months ago

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:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

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.

Krande commented 4 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!

stefano2734 commented 4 months ago

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.

Krande commented 3 months ago

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

Krande commented 2 months ago

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

image

stefano2734 commented 2 months ago

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.

Krande commented 2 months ago

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