I have produced the attached statics file which "seems" to be OK. I have been trying to conduct a buckling test with the same model but I am stuck. I would appreciate someone helping me (an amateur) set the model up for buckling analysis.
You can make these settings in Analysis settings: Analysis type: Buckling Modes: 3 or whatever Shift point: 1 seems to be OK. It should be lower than the lowest buckling factor but not too many orders of magnitude lower or the error increases.
Beware that the internal solver's buckling doesn't find buckling of individual truss members - you can do that by hand using axial force from Static 3D and the Euler buckling formula.
Be aware also that this is a pin-jointed truss. If you want rigid connections between members, turn off the Truss flag in Element properties for all elements.
For each mode it looks like the CCX method produces a buckling factor to multiply the total load by(?), whereas the Internal solver just gives the buckling loads. Also, I was somewhat annoyed CCX produced a bunch of different modes landing at the same buckling factor. (I asked for 200 modes.)
I agree with checking the individual members against local buckling. Your Static 3D analysis determined a max Strut compressive load of -16.7 kN, and a max Chord compressive load of -58 kN. (This is an easy check by filtering (hiding) your Components, then selecting Axial/Element).
There are a lot of Buckling Calculators on the web -- I prefer the Amesweb page because it has an internal algorithm which determines, by slenderness ratio, etc., whether the Euler calculation is appropriate or not, and lets you include some nominal eccentricities if you choose. Anyway, the Strut concentric buckling load calc'd to -22.6 kN, and the Chord concentric buckling load came out as -62 kN. This last result would have you operating a bit too close to the "red-line" (local failure).
~Cheers.
EDIT 9/21/2024. Correction posted later this date.
Gravity load shouldn't be inside the Buckle Step. I apply it in a previous step and then the Buckle is computed as a perturbation. That's because the self-weight doesn't scale, is always fixed no matter the external loads.
I recall a buckling analysis failing miserably on an electric tower containing trusses. Maybe something has change and this could be an opportunity to see if I find what was my problem but I would say Buckling/Frequency doesn't work with truss elements.
Thank you for all very much for your replies. When I was in school - some 60 years ago I was told by my teacher that is good to ask questions . So please excuse me and let me, an amateur (non engineer) ask:-
@cwharpe -"This last result would have you operating a bit too close to the "red-line" (local failure)." . That surprised me; perhaps I have given you the wrong impression of the member? It is 65mm square hollow section, 4mm wall thickness, length 1358mm,450MPa.
@disla - "I would say Buckling/Frequency doesn't work with truss elements.". How do you then calculate for failure in a truss element or am I misunderstanding your comment?
@LHartley - Well, I went back and sharpened my pencil. There were two discrepancies in the variables I used vs. your values. 1) Length: I had used the node-node member length (1500mm) vs. 1358mm. 2) I was looking at your 2nd model version, and entered the Mom.Inertia of the 30.34mm sq. Bar, instead of the Inertia of the SHS. Both errors throw results Way Off. Our respective calculators are now in agreement, and btw that SMath page is a nice presentation.
Incidentally, since the Mecway cross-sectional properties are calculated at the hard corners (no fillets), I've found an iterative solver (TKSolver) quite useful to quickly determine the equivalent dimensions that will match published values of Area and Inertia, e.g.: 65 x 4 SHS equivalent is ~ 63.69 x 3.848.
@LHartley Main drawback with truss elements is that to work properly and do not become a mechanism they should only have two nodes. They may work fine for static, but two nodes are insufficient to give good result in buckling analysis. See files.
If buckling factors of the elements defined as truss are lower (and wrong) than that for the same element defined as beam (see example file 77KN<496KN) , they alter the buckling analysis giving a bunch of nonsense modes or even no results at all. (ccx) If buckling factors of the elements defined as truss are higher (and wrong) than that for the same element defined as beam, you will miss a lot of local buckling modes (failure modes).
Internal solver can “manage” it up to a certain level but:
-it doesn’t allow to preload with self-weight before the buckling step (I haven’t found the way). -Using truss elements indiscriminately makes you miss all local buckling modes. -Doesn’t have NLBA for later checks.
Static analysis needs to be carefully inspected to detect any member that could end up in compression and avoid using truss elements there. I could provide more examples about what I’m talking.
I have built a buckling analysis file with trusses. The idea is to explore different work paths to see to which extent Mecway/ccx can solve a Buckling analysis of a structure involving this kind of elements.
It’s simpler than yours, with less members and a solution as reference to guide. Nevertheless, it faces the same problems as the 3D frame. This is a Linear Buckling Analysis without self-weight, imperfections, material safety coefficients, loads combinations ,...
As exposed above, members in compression have been converted to beam elements and the rest can be kept as trusses elements. I have computed the Euler Buckling load of the most critical element separately for checking purposes. 56.25KN
1-Static Step with everything truss elements. 2- Identify members in compression and convert them to beam elements. Refine. ( only the new beam elements). 3-Hinge joints on beams. (Flexible joint on beams). This way one can “recover” the original truss behavior but now beams can Buckle. 4-Move the analysis to buckling analysis and find Buckling load of the frame (-60*1.48 =-89.12 KN). Check buckling shape has sense. 5-CHECK: Move back to the Static analysis with the computed Buckling load (-89.12 KN) and check if Axial Load in the most critical member agree with the Euler buckling load (-56.25KN).
Is there a reason why Flexible joint on beams is red colored under Buckling Analysis?. It works and makes the difference, at least for this test. The test file uses the problem and solution exposed in this vid:
@disla - “ They may work fine for static, but two nodes are insufficient to give good result in buckling analysis. See files.” The difference is quite startling! This answered my question.
Now that I understand this I will attempt to revise my model based on your proposed approach - probably won’t be until next week as I am having a short holiday.
Thanks for the effort you have put into providing this information.
I would strongly recomend you to start with the simpler youtube model.
A reduced and simpler 3D version of your problem took some hours of trial and error to set up, keep the truss nature and remove all spurious modes. I have only obtained some results after adding additional members at the base. Keep in mind we are considering all truss elements and there is zero moment resistance on each beam/truss end.
I would not feel confident using this solver in a real-life project. I don't mean it's a solver problem , I mean I still need to find a more robust set up .
I'm obtaining a different result each time I press the run button and only after 5-10 runs a credible result pup up which by the way only fits my expected result if I keep the second buckling factor. In that case, the agreement is perfect.
Out of curiosity, why not just perform the member designs according to code based checks? I generally only check buckling through FEA if I am dealing with shell or solid elements.
I find it very annoying to have a fine mesh for line elements, especially since by line models are ever changing.
> I'm obtaining a different result each time I press the run button and only after 5-10 runs a credible result pup up which by the way only fits my expected result if I keep the second buckling factor.
Would you be able to send me that model? It sounds like a familiar problem but I'm not sure what. I can't think of anything you wouldn't already be aware of like free axial rotation of beams, inappropriate shift point, or members in tension having negative buckling factors. If this was somehow a pathological problem that breaks the buckling solver, I'd like to find out why that is.
> Is there a reason why Flexible joint on beams is red colored under Buckling Analysis?
It's not considered for the stress stiffness / geometric stiffness matrix. I'm not sure if that matters or not, so maybe it's correct or maybe not.
Good news, Just comment that Victor has been working on this and found a much better and reliable approach than mine. It involves more work to set up the model but he is working to make it easier adding some internal coding. Results are consistent with theory and now do not change in consecutive runs. By other hand, agreement between Euler theoretical buckling load and results are excellent. Overall output results also improved in readability. Hopefully, it will be incorporated in next versions. I will update the post with an updated liml once these features are released.
@disla - I got so far following your suggested workflow. Unfortunately I was only able to get as far as isolating the compression members which I have included in a named group. Then I got lost due to lack of expertise
I have attached both my static and buckling models together with some screen shots which I found quite interesting. I was expecting the colour scales to be symmetrical but I suppose the differing boundary conditions cause the slight variances.
The axial loads were about what I expected based in previous investigations so that gives me the sanity check for individual buckling and tear out checks.
When I was working I would have tested a model incrementally to destruction to see what it was capable of.
Your buckling analysis won’t be right. All the beam and truss elements only have two nodes so the buckling load will not be extracted correctly. I suggest you start with much simpler tutorials and models like the YouTube one. It has a known solution as reference. Now , the full model would be very hard to set up. Victor will try to simplify the workflow in next releases.
Looks like I missed one strut - 2 across and 2 up from the bottom left hand corner of the plan view.
Having thought about this question of buckling I have another few questions.
If the most critical member (chord or strut) failed the frame would become unstable - yes? If that is the case isn’t the buckling load for the frame the same as the buckling load for the individual chord or strut - or to use an analogy - the “weakest link”. Similarly with the tension members. Presumably the “tear out” load of the chord or strut with the highest tension loads would have to be identified.
So what I am driving at is would it be viable to calculate a safe working load for the frame based on a safe working load (safety factor) for the most critical member be it in compression or tension?
@LHartley only if there's no global buckling mode with a lower critical load. If you removed the guy wires, I imagine this truss/frame would begin to buckle globally before any individual member fails.
This are the You tube file and the simplified 3D Spaceframe file using the last refined set up. Its more work but the result is definitely worth it. Very accurate buckling loads compared to Euler. The buckling values obtained with LBA are those of Euler and not usable for construction. They must be corrected according to the different structural design rules.
EDITED: There is even a better set up. It is to constrain the axial rotation at a midspam node. That way problem can be analysed also with ccx LBA and NLBA sorting the "Error generating inp file: constraint equation not allowed on nodes with *TRANSFORM, which can be those with displacement constraints".
Comments
Analysis type: Buckling
Modes: 3 or whatever
Shift point: 1 seems to be OK. It should be lower than the lowest buckling factor but not too many orders of magnitude lower or the error increases.
Beware that the internal solver's buckling doesn't find buckling of individual truss members - you can do that by hand using axial force from Static 3D and the Euler buckling formula.
Be aware also that this is a pin-jointed truss. If you want rigid connections between members, turn off the Truss flag in Element properties for all elements.
Each connection in this model is a single bolt so I take it truss is OK.
I will let you know how I go.
Looks like I have a result.
Thank you
I agree with checking the individual members against local buckling. Your Static 3D analysis determined a max Strut compressive load of -16.7 kN, and a max Chord compressive load of -58 kN. (This is an easy check by filtering (hiding) your Components, then selecting Axial/Element).
There are a lot of Buckling Calculators on the web -- I prefer the Amesweb page because it has an internal algorithm which determines, by slenderness ratio, etc., whether the Euler calculation is appropriate or not, and lets you include some nominal eccentricities if you choose. Anyway, the Strut concentric buckling load calc'd to -22.6 kN, and the Chord concentric buckling load came out as -62 kN. This last result would have you operating a bit too close to the "red-line" (local failure).
~Cheers.
EDIT 9/21/2024. Correction posted later this date.
That's because the self-weight doesn't scale, is always fixed no matter the external loads.
I recall a buckling analysis failing miserably on an electric tower containing trusses. Maybe something has change and this could be an opportunity to see if I find what was my problem but I would say Buckling/Frequency doesn't work with truss elements.
@cwharpe -"This last result would have you operating a bit too close to the "red-line" (local failure)."
. That surprised me; perhaps I have given you the wrong impression of the member? It is 65mm square hollow section, 4mm wall thickness, length 1358mm,450MPa.
@disla - "I would say Buckling/Frequency doesn't work with truss elements.". How do you then calculate for failure in a truss element or am I misunderstanding your comment?
I have attached a screenshot of my efforts using SMath Solver.
The 65mm SHS properties can be found in Tablehttps://austubemills.com.au/resources/application-guide/design-capacity-tables-for-structural-steel-hollow/ 3.1-6(2) of this Design Table:-
Incidentally, since the Mecway cross-sectional properties are calculated at the hard corners (no fillets), I've found an iterative solver (TKSolver) quite useful to quickly determine the equivalent dimensions that will match published values of Area and Inertia, e.g.: 65 x 4 SHS equivalent is ~ 63.69 x 3.848.
Alternatively, just enter the catalog section properties under the General Section geometry tab.
@LHartley Main drawback with truss elements is that to work properly and do not become a mechanism they should only have two nodes.
They may work fine for static, but two nodes are insufficient to give good result in buckling analysis. See files.
If buckling factors of the elements defined as truss are lower (and wrong) than that for the same element defined as beam (see example file 77KN<496KN) , they alter the buckling analysis giving a bunch of nonsense modes or even no results at all. (ccx)
If buckling factors of the elements defined as truss are higher (and wrong) than that for the same element defined as beam, you will miss a lot of local buckling modes (failure modes).
Internal solver can “manage” it up to a certain level but:
-it doesn’t allow to preload with self-weight before the buckling step (I haven’t found the way).
-Using truss elements indiscriminately makes you miss all local buckling modes.
-Doesn’t have NLBA for later checks.
Static analysis needs to be carefully inspected to detect any member that could end up in compression and avoid using truss elements there.
I could provide more examples about what I’m talking.
I have built a buckling analysis file with trusses.
The idea is to explore different work paths to see to which extent Mecway/ccx can solve a Buckling analysis of a structure involving this kind of elements.
It’s simpler than yours, with less members and a solution as reference to guide. Nevertheless, it faces the same problems as the 3D frame.
This is a Linear Buckling Analysis without self-weight, imperfections, material safety coefficients, loads combinations ,...
As exposed above, members in compression have been converted to beam elements and the rest can be kept as trusses elements.
I have computed the Euler Buckling load of the most critical element separately for checking purposes. 56.25KN
1-Static Step with everything truss elements.
2- Identify members in compression and convert them to beam elements. Refine. ( only the new beam elements).
3-Hinge joints on beams. (Flexible joint on beams). This way one can “recover” the original truss behavior but now beams can Buckle.
4-Move the analysis to buckling analysis and find Buckling load of the frame
(-60*1.48 =-89.12 KN). Check buckling shape has sense.
5-CHECK: Move back to the Static analysis with the computed Buckling load (-89.12 KN) and check if Axial Load in the most critical member agree with the Euler buckling load (-56.25KN).
@Victor Kemp
Is there a reason why Flexible joint on beams is red colored under Buckling Analysis?. It works and makes the difference, at least for this test.
The test file uses the problem and solution exposed in this vid:
Now that I understand this I will attempt to revise my model based on your proposed approach - probably won’t be until next week as I am having a short holiday.
Thanks for the effort you have put into providing this information.
A reduced and simpler 3D version of your problem took some hours of trial and error to set up, keep the truss nature and remove all spurious modes.
I have only obtained some results after adding additional members at the base. Keep in mind we are considering all truss elements and there is zero moment resistance on each beam/truss end.
I would not feel confident using this solver in a real-life project. I don't mean it's a solver problem , I mean I still need to find a more robust set up .
I'm obtaining a different result each time I press the run button and only after 5-10 runs a credible result pup up which by the way only fits my expected result if I keep the second buckling factor.
In that case, the agreement is perfect.
A similar model is solved in Abaqus
https://numericalarchive.com/product/double-layer-space-frame-using-abaqus/
I find it very annoying to have a fine mesh for line elements, especially since by line models are ever changing.
It can also be used to extract buckling shapes to build the initial imperfections for the NLBA analysis.
Or frequency analysis to find the response of a framework intended to support a rotatory machine.
Here it's just an exercise to see if Linear Buckling agrees with Linear Static.
> I'm obtaining a different result each time I press the run button and only after 5-10 runs a credible result pup up which by the way only fits my expected result if I keep the second buckling factor.
Would you be able to send me that model? It sounds like a familiar problem but I'm not sure what. I can't think of anything you wouldn't already be aware of like free axial rotation of beams, inappropriate shift point, or members in tension having negative buckling factors. If this was somehow a pathological problem that breaks the buckling solver, I'd like to find out why that is.
> Is there a reason why Flexible joint on beams is red colored under Buckling Analysis?
It's not considered for the stress stiffness / geometric stiffness matrix. I'm not sure if that matters or not, so maybe it's correct or maybe not.
Just comment that Victor has been working on this and found a much better and reliable approach than mine. It involves more work to set up the model but he is working to make it easier adding some internal coding.
Results are consistent with theory and now do not change in consecutive runs. By other hand, agreement between Euler theoretical buckling load and results are excellent. Overall output results also improved in readability.
Hopefully, it will be incorporated in next versions. I will update the post with an updated liml once these features are released.
I have attached both my static and buckling models together with some screen shots which I found quite interesting. I was expecting the colour scales to be symmetrical but I suppose the differing boundary conditions cause the slight variances.
The axial loads were about what I expected based in previous investigations so that gives me the sanity check for individual buckling and tear out checks.
When I was working I would have tested a model incrementally to destruction to see what it was capable of.
Thanks again.
I suggest you start with much simpler tutorials and models like the YouTube one. It has a known solution as reference. Now , the full model would be very hard to set up.
Victor will try to simplify the workflow in next releases.
Having thought about this question of buckling I have another few questions.
If the most critical member (chord or strut) failed the frame would become unstable - yes?
If that is the case isn’t the buckling load for the frame the same as the buckling load for the individual chord or strut - or to use an analogy - the “weakest link”.
Similarly with the tension members. Presumably the “tear out” load of the chord or strut with the highest tension loads would have to be identified.
So what I am driving at is would it be viable to calculate a safe working load for the frame based on a safe working load (safety factor) for the most critical member be it in compression or tension?
@ - thank you. I will watch out for your post.
The buckling values obtained with LBA are those of Euler and not usable for construction. They must be corrected according to the different structural design rules.
EDITED: There is even a better set up. It is to constrain the axial rotation at a midspam node. That way problem can be analysed also with ccx LBA and NLBA sorting the "Error generating inp file: constraint equation not allowed on nodes with *TRANSFORM, which can be those with displacement constraints".