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
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.
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.
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.
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.
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”.
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
@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.
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.
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.
)
