Hi
I tried to test a shelf stuck at the base by applying an axial load to the opposite end.
The profile has dimensions 100x100 mm, length L= 3000 mm, material S355 steel
The Eulerian critical load is equal to P=EJ3.1415^2/(4*L^2) = 470’437.10 N (47’974.41 kgf). Carrying out the calculation with load P the result is equal to Buckling Factor = 1.02 and therefore substantially correct. By applying a load equal to P1= 980’665 N (100’000 kgf) the result is equal to Buckling Factor = 4.374 (??). Is this my error or a bug? Thanks for your help
1 Like
Are you sure it’s the first buckling mode ? Is the mode shape the same ? What if you apply a unit load as it’s often done this way ?
Yep, I would also check if it is the first mode because 48 Tn seems like a lot to me. Could elaborate a bit more on how did you arrived to your result using that formula?
I confirm that it is the first mode. The form of the mode is different. By applying a unit load the buckling factor is correct
the load was determined based on the Eulerian critical load Pcr= EJPigrec^2/(4*L^2)
Why are there two steps with the first one being linear static ?
I submitted the input file from your analysis (just without the redundant static step) in Abaqus and got the right answer: 0.48973 so this seems to be a CalculiX bug. The second eigenvalue reported by Abaqus was 4.3919 so CalculiX probably just skipped the first one (hence the different mode shape).
Oh. It is a 100x100 solid section of S355.Ok.
FEA will probably match your hand formula, but Euler formula requires a minimum slenderness to be usable.
The critical load occurs when L>10x"a" with “a” minimum section size, a condition satisfied in the example. I wonder if the bug can be fixed in a short time
Thanks for the replies
If you check the CalculiX forum, you will see that there might still be some issues with eigenvalue calculations. It’s best to report the new ones here: Issues · Dhondtguido/CalculiX · GitHub
Your are absolutely right ,Your beam is 3m. Sorry Agazzotti. I need to check my glasses.
Maybe using another solver will help? Pardiso or Spooles?
I checked different solvers than Pardiso (used by the OP). Spooles gave even worse results. PaStiX didn’t help either.
Mine is ok but I had to delete the analisys and create a new one.
480 KN
If Buckling Factor is close to one the load must be reduced. Pardiso.
This depends on the number of processors. If you don’t use more than two for Spooles, you get the same results (ccx v2.21)
Spooles with 2 processors:
1 0.4374943E+01
2 0.4375175E+01
3 0.1198231E+02
4 0.1198349E+02
Spooles with 4 processors:
1 0.6292859E+00
2 0.2291324E+01
3 0.4445474E+01
4 0.4787324E+01
I used a coarser mesh so the values are slightly different
I have to correct myself, the results seems to be random and vary for each calculation…
This has shown on different posts on the ccx forum.
Ccx struggle to extract the right value if the initial load is larger or close to the eigenmode.
One should start as low as possible and search for buckling factors always larger than 1.
0.6292859E+00
This is not a reliable solution.
1 Like
Have you tried increasing the accuracy? The default is 1E-2, I did some investigations in the past and found that at least 1E-4 should be used when requesting a few eigenmodes. Maybe the following issue I’ve opened in GitHub may help.
Changes in *BUCKLE definition · Issue #57 · Dhondtguido/CalculiX (github.com)
I mean there is a problem with Spooles when using more than two processors.
In the example the beam is 10x10x200 and loaded with 1N. I made four calculations in a row using four processors, the results are:
As long as i use Spooles with 1 ore 2 processors, it gives the same constant values like pardiso and pastix:
1 0.1079842E+05
2 0.1079850E+05
3 0.9563834E+05
4 0.9563858E+05
ccx 2.21
It seems to be a good example to showcase various issues with linear buckling that are still present in CalculiX. Definitely worth documenting on the ccx GitHub repo so that it doesn’t get lost here. Maybe even sharing directly with Guido. The number of unresolved bugs is growing and it might be a good time to send another reminder to Guido (I’ve sent a few in the past) so that he at least takes a look at those open bug reports. There are even PRs with solution proposals.
