Buckling of composite panels

[peter_g]

Hi, I want to use Calculix to optimise the buckling performance of a wind turbine blade. Calculix is perfect because it can be used on as many cores (great for optimisation) as I want without it looking for a license or me having to pay out extra like I would for ANSYS or ABAQUS.

I’ve created a script to set up the problem and it can write to ANSYS or ABAQUS - with both solvers I get a a buckling factor of 1.4 with my test case. However, with Calculix for Windows (the BConverged binary) I get a buckling factor of 0.52 and in a different area of the blade, but for a static analysis the results agree reasonably well. I’m wondering if anyone who is using a more up to date version of Calculix on Linux would be able to give me any pointers of things to try to get agreement between the codes? Or is compsoites buckling a known problem with Calculix and I should give up?

The input deck can be downloaded from here: blade_sect.inp - Google Drive

Any help will be much appreciated!

[Calc_em]

The bConverged version is very old. Here you can find the newest binary for Windows:

http://www.dhondt.de/

[Disla]

Hi Peter G,

Looks like you work with complex distributions of orthotropic materials in different layers. Very interesting.
Some time ago when looking at ortho materials I found there was some rules to be satisfied by the different material properties.
I wouldn’t want to lose the opportunity to test it and comment with you if I’m understanding them properly.
For example, Carbon UD has some properties that doesn’t fit ( B. M. LEMPRIERE) criterion. Is it something that can be avoid or maybe are not of much importance?
¿Didn’t you experience any convergence issue?

[peter_g]

It’s true and it looks like you found a good source! My biax [+/-45] material has smeared properties, and the Poisson ratio has been altered to (from 0.54 as calculated by classical laminate theory) to 0.49 so that ABAQUS and ANSYS will allow it to be used. I’m assuming that as I am using shell elements in Calculix the out of plane properties don’t matter?

[peter_g]

Thanks for your response @Calc_em and @Disla - it seems with these newer binaries I get a different but still wrong buckling factor… 6.6 instead of 1.4 (from two commercial solvers), old version of Calculix was giving 0.52. Do you know of anything I could tweak in the settings for *BUCKLE?

[Disla]

Oh, So it’s ok to manually adjust it. Thans for sharing.

Regarding your solution be sure to use Pardiso Solver. Reduce your initial load /10 .
Increased accuracy works typically to get a better shape not buckling factor, but you can try one order of magnitude.

*BUCKLE

….,1e-4

EDITED. Is it giving a solution to you.?
This what I obtain. It doesn’t even find a solution. I would say Kinematic is not working and it is not appling any load.

sigma=0.000000,d[0]=0.000000
no convergence for the buckling factor; maybe no buckling occurs

Maybe coupling works in Linux. I’m a windows user.

[JuanP74]

I reversed the loads due to this Wrong eigenvalue calculation since v2.16 and get 0.98 (ccx v2.20 spooles)

running your file directly in v2.20 with spooles I got 2.18 (let me know if in abaqus the buckling factor was positive or negative)

What is clear is the difference in location that might be attributed maybe to the load coupling behaviour or the knots overstiffening the shells in ccx at the intersection of spars/skins

[Disla]

¿Could you try increasing the accuracy?. It makes a big difference in the eigen shapes.

Why it doesn’t work for me in windows

Oh. I see

[Disla]

This inp has some numbers with more than 20 Chars.

*ELASTIC, TYPE=ISO
1000000000000000.000000,0.300000

*Buckle is not working for me.
Win 10 Pro and ccx pardiso V2.19 MKL OOC

[JuanP74]

I didn’t explained it properly.

CalculiX (just as ABAQUS) reads reals with the f20.0 Fortran format.

https://docs.oracle.com/cd/E19957-01/805-4939/z40007439c43/index.html

[JuanP74]

I don’t have problems running it in v2.19 spooles or pardiso. Looks like Pardiso does not have the negative eigenvalues issue. Probably @peter_g run it with pastix which is default for static but does not work for eigenvalue extraction.

[Disla]

Hi Juan,

But are you able to obtain an eigenvalue , a buckling factor with *BUCKLE, or are you performing a nonlinear buckling analysis.?

Kinematic is not coupling correctly when I switch to Buckling nor Modal vibrating analysis.
I can see you have a Time value on your picture.

[JuanP74]

In cgx Time is pseudotime (percent load) in statics, time in transient dynamics, frequency in modal analysis, eigenvalue in buckling etc.

I just took the file and run it in ccx v2.20 spooles compiled by myself for macOS and v2.19 and v2.20 spooles and pardiso from PrepoMax I think…all of them run.

[JuanP74]

these are my files blade_sect - Google Drive

[lucas_bueno]

When I run your file without modifications in CalculiX 2.19, I get a minimum eigenvalue of 3.45

[lucas_bueno]

Changing the input file to the following:

I get 0.98, 1.01 and 1.03, all of them with almost the same buckled shape:

EDIT: Actually, these results are entirely wrong. I reduced the load to a fraction of 100 and the eigenvalues are still close to 1 - must be some default value CalculiX outputs in case of error.

[JuanP74]

might be an issue like the one described here [1910.08652] On the shift-invert Lanczos method for the buckling eigenvalue problem as I modified CCX to allow input of the shift value in the *BUCKLE card and I get always that the eigenvalue is closer to the selected shift value…I tested it with some other problems and you really need to shift a lot away from the “right” eigenvalue in order to arpack cast a different eigenvalue.

For beam8b.inp test file I had to input

 Calculating the buckling factors and buckling modes:

sigma=1000.000000,d[0]=838.589743

in order to get a different eigenvalue.

[fgr]

Hereby my contribution to this issue.

I have run my test with the untouched blade_sect.inp

Windows
Compiling with the -DUSE_MT option gives successive random results for both the 4 and 8 byte integer versions of CCX_2.20.

The accuracy value in Buckle Card doesn’t seem to have any effect at all, and for a value below 0.000001 it will be defined as 0.0 Personal in such cases,I would have expected it to be define as the minimum accepted value.

For CCX_2.20 4 byte integer with Spooles solver
successive stable results
sigma=1.000000,d[0]=1.575535
sigma=1.000000,d[0]=1.575535

same compilation but with Pardiso solver
consecutive random results

For CCX_2.20 8 byte integer with Spooles solver
successive stable results
sigma=1.000000,d[0]=1.575535
sigma=1.000000,d[0]=1.575535

For the Spooles solver, minor change of the E-modules also gives results with minor change of the buckling factor.
I have previously run some of the eigenvalue test examples for the Spooles solver on this page, and with these examples my compilation of the Spooles solver matches the Pardiso solver.

Linux Debian
Compiling with the -DUSE_MT option gives successive random results for both the 4 and 8 byte integer versions of CCX_2.20.

For CCX_2.20 4 byte integer with Spooles solver
successive stable results
sigma=1.000000,d[0]=1.575535
sigma=1.000000,d[0]=1.575535

For CCX_2.20 8 byte integer with Spooles solver
successive stable results
sigma=1.000000,d[0]=1.575535
sigma=1.000000,d[0]=1.575535

So my conclusion will be:
Using the -DUSE_MT option produces random results.
The accuracy value does not seem to have any effect.
The Spooles solutions seem to give stable results although they deviate from the results found by Ansys and Abaqus. Currently I don’t have any explanation for the difference between CCX and Ansys/Abaqus

[jbr]

@fgr

The Spooles solutions seem to give stable results although they deviate from the results found by Ansys and Abaqus. Currently I don’t have any explanation for the difference between CCX and Ansys/Abaqus

I have experienced exactly the same issue in the past. I typically go for Pardiso, much more reliable in this case.

[Disla]

If this is a solver problem, ¿why *FREQUENCY works?¿Isn’t it essentially the same?

I think there are much lower buckling modes that don’t allow the global Buckling ones to show up.

As soon as I apply a load to the model , looks like there is a complete lack of stiffness between some of the layers.

Like local buckling modes at an element scale. Kind of hourglass.

An individual *frequency analysis of each of the materials show up that some of them have more than 6 free body modes. Those are hourglass modes o lack of stiffness on specific directions.

0.090,Carbon_UD,OR935 Wrong Free Body Modes
0.030,medium_density_foam,OR935 Ok
0.030,Glass_UD,OR935 Ok
0.030,Glass_biax,OR935 Wrong Free Body Modes
0.030,Gelcoat,OR935 Ok
0.030,resin,OR935 Ok
0.030,Steel_S355,OR935 Ok
0.030,LE_Material,OR935 Wrong Free Body Modes
0.030,Adhesive,OR935 Ok
0.030,WebDUmmyMat,OR935 Ok
0.030,unobtainium,OR935 Ok

¿I ask myself if the shift point dependance is because properly stablished can “jump” all those local modes?