# Shell Buckling Analysis

**URL:** <https://prepomax.discourse.group/t/shell-buckling-analysis/2990>\
**Category:** General Questions\
**Created:** [October 2, 2025, 7:03pm UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990 "2025-10-02T19:03:24Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![MaraJaatinen](https://avatars.discourse-cdn.com/v4/letter/m/839c29/32.png) [@MaraJaatinen](https://prepomax.discourse.group/u/MaraJaatinen)\
**Post date:** [October 2, 2025, 7:03pm UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/1 "2025-10-02T19:03:24Z")

</div>

Hi all!

I’m working on a shell I-beam buckling analysis. I’m having trouble making heads or tails of this. I suspect the issue may be with with the rigid bodies I’m trying to set up. I want the beam face at the support end to act as a pinned joint about the Y-axis, the support at 1 meters is rotated 45° and fixed only in the local coordinate system’s Z-axis. This is supported with a rigid link to a 500 mm edge at the middle of the top flange. The reference points near existing nodes are offset by ≈ 1 mm so there should be no interferance.

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/b/b76bcd6f622c5c5d51108ed8f66a55824c508558.jpeg)

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/8/8ee4469ee6359805f04e30d6a49864715245b043.jpeg)

The point load Q is to be placed at the free end at the tip of the bottom flange. I can’t seem to be able to get a sensible result from the buckling analysis. I was excited because I initial input the critical moment and got a buckling factor of ≈ 0,97. However, I get the same kind of result regardless of the point load at the end.

Any support would be much appreciated!

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/2/21116791bfd42d54254e2c43bc13d0a9d6a9f442.jpeg)

[Mcr.pmx](https://prepomax.discourse.group/uploads/short-url/wLXB8w8af2Y7VDYLX379Qw63wP7.pmx) (8.4 MB)

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [October 2, 2025, 8:57pm UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/2 "2025-10-02T20:57:41Z")

</div>

It might be better to specify a unit load for linear buckling analyses. Also because otherwise CalculiX may miss the first buckling mode: [First buckling mode skipped when applied load is much bigger than buckling load · Issue #74 · Dhondtguido/CalculiX · GitHub](https://github.com/Dhondtguido/CalculiX/issues/74)

There are known CalculiX issues with shells too (due to their internal expansion to solids). It’s often better to try with solid elements when encountering problems like that. In PrePoMax, it’s really easy since you can use the Thicken Shell Mesh tool to quickly create a solid mesh from your shell mesh. Some analysis features have to be redefined though.

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [October 3, 2025, 7:35am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/3 "2025-10-03T07:35:18Z")

</div>

Hi,

It’s good practice to first run a frequency analysis to check there are no rigid body modes or disconnected parts that will mess the Buckling analysis.

Additionally, I have experienced some Buckling analisys problems with shells and offsets in the past. I would try if removing offsets solves the problem. If yes, then I would go to solid elements as workarround if you need that extra accuracy.

---

<div class="post-metadata">

**Author:** ![MaraJaatinen](https://avatars.discourse-cdn.com/v4/letter/m/839c29/32.png) [@MaraJaatinen](https://prepomax.discourse.group/u/MaraJaatinen)\
**Post date:** [October 3, 2025, 7:36am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/4 "2025-10-03T07:36:14Z")

</div>

Thanks for the quick response!

I assume by a unit load, you mean for example 1 N or 1 kN.

The issue I’m having is that even with a load that minimal, the buckling factor is non-sensicle.

For example, with 1 N the buckling factor is:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/3/32db5de1f1b40e55c3162199491471e5f9af7a27.png)

And with 1 kN:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/2/236fe2d7ffca88f1bd0b2a167eeac9b5fc03c794.png)

Could this be the known calculix issue or could something simpler be wrong with my model?

I was playing around with the rigid link at this “cylinder” support:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/c/cd2aabace48cf46d5ef96ef05e14019be43325ce.jpeg)

Currently it’s tied to the edge of the web for a span of 500 mm. When I change it to the flange edge or the whole web area below, the buckling factors become more realistic. I think I’ll model a shell lug for the cylinder support to see if that helps.

Also the rigid links at the ends - they appear unsymmetrical but is that just a graphical representation issue?

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/4/4b834a68847066ea11c5452e7ae8c5ee5429f562.jpeg)

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [October 3, 2025, 8:19am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/5 "2025-10-03T08:19:52Z")

</div>

> [@MaraJaatinen](#):
>
> Could this be the known calculix issue or could something simpler be wrong with my model?

It sounds more like something unconstrained or some disconected part.

I would try to animate the first five/six frequency modes to see if it vibrates as expected.

---

<div class="post-metadata">

**Author:** ![Matej](https://avatars.discourse-cdn.com/v4/letter/m/a698b9/32.png) [@Matej](https://prepomax.discourse.group/u/Matej)\
**Post date:** [October 3, 2025, 9:22am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/6 "2025-10-03T09:22:46Z")

</div>

I tried removing rigid body constraints from your model and applied BCs and loads to single nodes (create node sets), and the model works as expected. I think rigid body connections are to blame.

Maybe add additional shell elements with a large thickness instead of a rigid connection. Or try adding kinematic or distributing coupling by keywords.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [October 3, 2025, 9:40am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/7 "2025-10-03T09:40:19Z")

</div>

> [@MaraJaatinen](#):
>
> I assume by a unit load, you mean for example 1 N or 1 kN.

Yes, this way you don’t have to multiply the buckling factor by the applied load. And you avoid the aforementioned ccx issues.

> [@MaraJaatinen](#):
>
> Also the rigid links at the ends - they appear unsymmetrical but is that just a graphical representation issue?

This is purely graphical. As long as the edges in selection (highlighted in pink here) are the right ones, rigid body constraint will be applied to the desired region. Those spider link symbols don’t always cover all the relevant areas to reduce the clutter in the viewport.

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [October 3, 2025, 9:22pm UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/8 "2025-10-03T21:22:05Z")

</div>

I have built one from scratch with three rigid bodies and it works (even with the shell offsets)

I haven’t compared it with any reference solution. Maybe there is something with your geometry or element type. I’m using Pardiso.S8R

 ![screenshot.26](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/2/2ba18f6c3d3c28ec4fd25fc88cddc357840b186f.jpeg)

 ![screenshot.25](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/b/b8b90813e9ba1a868f7e3b2a70329adff0de469b.jpeg)

[Buckling IPE300\_Prepomax.inp](https://prepomax.discourse.group/uploads/short-url/d5fZyyAozNTtpyxfLkxZI20JqAc.inp) (547.8 KB)

---

<div class="post-metadata">

**Author:** ![MaraJaatinen](https://avatars.discourse-cdn.com/v4/letter/m/839c29/32.png) [@MaraJaatinen](https://prepomax.discourse.group/u/MaraJaatinen)\
**Post date:** [October 4, 2025, 6:19am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/9 "2025-10-04T06:19:44Z")

</div>

Thanks everyone for the input and help!

I think what made the most difference was replacing rigid links to edges with rigid links to node sets.

This 2nd support fails completely:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/b/b69a9374e83d93a52f9fc0b9ed0ba00c2c12ff02.jpeg)

While this works just fine with the same method:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/7/71944898e0ca414b5b01d2962e16ac15304681ba.png)

I ended up supporting as so:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/6/60c348a4469cf7ae4f70d97addf07185ac7fb1fc.jpeg)

It isn’t exactly the same but for this purpose I believe is works well enough.

Another issue I keep running into with shell models is edge/surface ties. They seem to fail constantly. For example, this lifting lug:

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/f/f8be710180287c5a76912e027c294fffa9d72d74.jpeg)

I’ve also had the web come completely loose from the flanges. I’d like to merge/compound parts but of course I can’t do that with different shell thicknesses. Is there a guide somewhere that gives the best modelling practices? I tried to match the meshes so that nodes line up but I’m having trouble generating meshes that are completely in line.

Thanks to everyone once again!

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [October 4, 2025, 7:15am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/10 "2025-10-04T07:15:51Z")

</div>

> [@MaraJaatinen](#):
>
> I think what made the most difference was replacing rigid links to edges with rigid links to node sets.

Internally, this edge selection is converted to node set as well, but including midside nodes which you apparently skipped in your second approach with manual node selection.

> [@MaraJaatinen](#):
>
> Another issue I keep running into with shell models is edge/surface ties. They seem to fail constantly.

Increase the position tolerance and it should work.

> [@MaraJaatinen](#):
>
> I’d like to merge/compound parts but of course I can’t do that with different shell thicknesses.

You can assign different thicknesses to faces of a compound surface part, but compounding may fail in some cases with surface geometries: [Deformation in 2 or more bodies - #10 by Matej](https://prepomax.discourse.group/t/deformation-in-2-or-more-bodies/524/10) and [Contact Generations issue Shell\_Solid - #16 by Matej](https://prepomax.discourse.group/t/contact-generations-issue-shell-solid/981/16)

> [@MaraJaatinen](#):
>
> I tried to match the meshes so that nodes line up but I’m having trouble generating meshes that are completely in line.

This usually isn’t necessary and you can use tie constraints (unless you e.g. calculate fatigue of welds with some special methods). But you could try enforcing equivalent number of nodes with local refinement and then there is a tool to merge nodes that are close to each other (lie within a specified distance): Model —\> Node —\> Merge Coincident Nodes.

---

<div class="post-metadata">

**Author:** ![MaraJaatinen](https://avatars.discourse-cdn.com/v4/letter/m/839c29/32.png) [@MaraJaatinen](https://prepomax.discourse.group/u/MaraJaatinen)\
**Post date:** [October 4, 2025, 8:26am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/11 "2025-10-04T08:26:54Z")

</div>

> [@FEAnalyst](#):
>
> This usually isn’t necessary and you can use tie constraints (unless you e.g. calculate fatigue of welds with some special methods). But you could try enfo

Thank you! I’ll try some of these solutions next. Luckily I had to change profiles during an optimisation phase so I’m having to redo everything in any case!

---

<div class="post-metadata">

**Author:** ![MaraJaatinen](https://avatars.discourse-cdn.com/v4/letter/m/839c29/32.png) [@MaraJaatinen](https://prepomax.discourse.group/u/MaraJaatinen)\
**Post date:** [October 4, 2025, 9:02am UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/12 "2025-10-04T09:02:48Z")

</div>

Compound part with different thicknesses on faces was the simplest method and is looking very sensible indeed! I don’t know why my brain was stuck in a loop thinking compound couldn’t be doable with different thicknesses. Just goes to show - you’re limiting yourself if you don’t ask dumb questions!

Thanks again. Hope this convo helps someone else along the way!

 ![image](https://global.discourse-cdn.com/free1/uploads/prepomax/original/2X/5/58cf440295a6c29ce32b8755f81de2028d2c1a64.jpeg)

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [October 5, 2025, 7:52pm UTC](https://prepomax.discourse.group/t/shell-buckling-analysis/2990/13 "2025-10-05T19:52:48Z")

</div>

> [@MaraJaatinen](#):
>
> This 2nd support fails completely:

Hi Mara.

¿May I ask if the analisys is not completing or the result is not as expected.?

I can’t reproduce the problem or detect anything wrong.

Thanks
