Wrong eigenvalue calculation since v2.16

Hi there,

I have this example (file attached buckling error example.zip - Google Drive) where in versions older that 2.16 the result is ok:

sigma=1.000000,d[0]=0.998325

no convergence; new iteration

 Factoring the system of equations using the symmetric spooles solver
 Using 1 cpu for spooles.

 Calculating the buckling factors and buckling modes:

sigma=0.001997,d[0]=0.033631

 Using up to 1 cpu(s) for the stress calculation.


 Job finished

but for v2.16 and on (I checked the latest 2.19 just downloaded from Dhondt site under linux) and I get the following:

 Factoring the system of equations using the symmetric spooles solver
 Calculating the buckling factors and buckling modes:

sigma=1.000000,d[0]=0.998325

 Using up to 1 cpu(s) for the stress calculation.


 Job finished

Anyone has experienced issue like this one?

Thanks in advance.

I can confirm this bug. Here are the results obtained using different versions for Windows:

Yes. Buckling factors can no longer be much less than 1. You might work around it by reducing the load to be always below critical load. There’s a bit of code you can uncomment and recompile to correct this in arpackbu.c:

  if((5.>d[0]/sigma)||(50000.<d[0]/sigma)){
	if(iconverged<-4) {
	printf("no convergence for the buckling factor; maybe no buckling occurs");
	FORTRAN(stop,());
	}
	sigma=d[0]/500.;
	printf("no convergence; new iteration\n\n");
	--iconverged;
	SFREE(z);SFREE(d);
	}
	else{iconverged=0;}

The ARPACK eigenvalue solver needs a “shift point” to give it a lower bound on the buckling factor, and I think this older code automatically searches for that, while versions without it just set it to 1. It looks like the value is displayed in the output as sigma like:

sigma=1.000000,d[0]=35.274484

I think Guido disabled that code because it sometimes found the wrong value and resulted in incorrect buckling factors.

1 Like

Thanks for the response.

Do you have any examples of the previous code errors (pre v2.16)? I’ll try to find a solution for both situations (not guaranteed I will succeed :grimacing:)

That would be excellent. Here’s an example that gives negative buckling factors with CCX 2.15. You can see when you solve it that it gets a negative eigenvalue on the 2nd iteration and then sigma goes negative and everything falls apart.

hi there. I guess this is not a good example because the negative eigenvalues are the right ones…so still the pre v2.16 solution is OK and newer versions are wrong…

Can you show how they’re right? I imagine it’s because some members are loaded in tension. But there should still be global buckling and local buckling of the compression members. How would we find that? Is it not right to exclude negative eigenvalues from a buckling solution?

Is it not right to exclude negative eigenvalues from a buckling solution?

No, is not. Negative eigenvalues just show that the buckling load is “opposite” to the applied loads.

Can you show how they’re right?

I checked the result with a different software (As I did with the perforated panel). However in this case as 1st buckling eigenvalue is local (see attached pic) probably hand calculation to check it is enough.

Probably there are many local modes in this structure. If you’re looking for a global buckling mode more eigenvalues have to be requested. Should finally appear…
BTW it’s funny that ccx orders negative eigenvalues starting from biggest absolute value.

I agree with JuanP,

A negative Buckling factor has perfect sense physically and numerically but maybe not in the context of the solution you are searching. The buckling factor gives the number which once multiplied by the applied load , allow us to foresee when the corresponding buckling mode would show.
It is a scaling factor and when negative , It means that the same applied load but with opposite direction, will cause buckling.

Try to solve the same problem but with the force in opposite direction. It will buckle and if they have appeared the most probable is that it does it at a lower buckling factor value than the one you are searching.
If you do not foresee load reversal , don’t worry. If it is possible, be careful.

I see. I’ll try to dig up the original model that this one is extracted from. Maybe they were all OK after all.

Ordering from biggest absolute value (or smallest actual value) would be sensible if there were both positive and negative modes in the same solution. I guess that’s just what comes out of ARPACK.

Removing the sign of the buckling factor is probably the source of confusion.

Ordering from biggest absolute value (or smallest actual value) would be sensible if there were both positive and negative modes in the same solution.

The standard in Nastran is to order them by absolute value despite they are negative or positive because this is the logical order in physical terms, the lowest loads go first independently if they are same (or opposite) sign than the applied loads.

1 Like

So then, there was still a real issue with older versions? or, are newer versions wrong? This has to be clarified because current implementation misses the right solution in many cases.

I’m not confident anymore that there was really a problem with the older versions. But there’s definitely a problem with newer versions so I always re-implement that sigma searching code to keep the old behavior. I’m now waiting for permission to share the model that kicked all this off and I’ll post it here if I can. These are the only cases I know of that show the “bug”.

¿From where could this old CCX versions be downloaded?.
¿Is there a repository of old windows compiled versions? V2.15 and V2.16

for windows you can download old prepomax versions. in the Solver folder you have the compiled ccx .exe and you have many versions v0.5.1 for example is v2.15 and v1.1.0 is v2.16…I got the versions I have from the time they were released…some in Linux, some in windows, and I have v2.17 I compiled for macOS 10.13

Thank you, Juan.

@Vicmw. I think I have one of these unicorns with negative eigenvalues. It was related with a cylindrical shell under internal pressure and very small thickness. Just a weir (mostly wrong) result which was finally solved increasing thickness.

Looking back at my emails with the person who brought this up, I see the problems were more complicated and I don’t think the change in v2.16 really addressed them but I haven’t checked.

 # TABLE 1:  "Linear 1st Buckling factor"
    Ccx2.13         Ccx2.15         ANSYS
      B31   B31R  B31   B32R  B32  BEAM188
------------------------------------------
 2  2.397  8.556 2.433 1.583 2.051  1.100
 4  1.309  2.045 1.539 2.161 1.897  1.103
 6  1.202  0.859 1.715 3.489 2.298  1.103
 7  -0.09  0.626   -     -     -    1.103
 8  -0.07    -     -     -     -    1.103
 9  -0.07  0.385 -0.07 6.572 4.770  1.103
19  -0.06  0.109 74.72 -0.06 53.67  1.103 
* Some results were not computed (indicated by "-").

The first column is the number of elements per member. Here’s the file for 2 elements per member and B31:

All the models were the same structure but with only the mesh refinement and element types changed.

I wonder if perhaps the coarser meshes were just not capable of revealing the true negative buckling factors and all those positive ones were various different amounts of error.

I hope you can share it.

Hi. My first impression is that those differences aren’t related to eigenvalue extraction issues but modelization issues.
Beams in ccx are very particular as they are limit cases of 3D brick elements so I guess you have to be very careful choosing the modelization. It seems (see picture) that buckling is local for helical members so I’d try to simulate a single item of that type and compare to theoretical Euler buckling load and try to select the appropriate combination of mesh refinement and element type. The kinks in the deformation plot do not look pretty well so I’d doubt the results.