Pinned-base portal frame under gravity load

Open the Frame Calculator and use the command line at the bottom. Typing is not a shortcut for the mouse here — it is how you get the exact geometry. A portal drawn by eye is a portal whose span you cannot quote.

Place the four corners — left base, left eaves, right eaves, right base:

N 0,0 N 0,4 N 6,4 N 6,0

Then connect them. M 1 2 means “a member from node 1 to node 2” — the left column:

M 1 2 M 2 3 M 4 3

Note the last one runs 4 → 3, not 3 → 4. Both columns then point upward, so their local axes agree and the member end forces in the results table can be compared side by side without mentally flipping one of them.

Both bases are pinned: they hold the frame down and stop it sliding, but they let the column rotate. In the command line, S 1 P reads “node 1 is pinned”:

S 1 P S 4 P

This single choice separates two completely different structures. A pinned base carries no moment, so the foundation only ever sees a vertical load and a horizontal push. A fixed base carries moment too — a stiffer frame, but a much more expensive footing.

Pinned bases make this frame once statically indeterminate: three equations of statics, four unknown reactions. Statics alone will not finish the job, which is exactly why the solver earns its keep here.

Give every member the same section to begin with — ,, , which is close to a 310UB. In the Member Properties table this is group 1; all three members already point at it.

Then load the rafter with downward. On this site gravity is negative — down is the negative y direction, so the value is:

L 2 -10

That is the whole model: four nodes, three members, two supports, one load. The results appear as you type — there is no separate solve button to press.

Vertical equilibrium does not care that the frame is indeterminate. The whole load has to land on the two bases:

And the frame is symmetric — same geometry, same section, same load about the centreline — so the two bases share it equally:

The solver agrees exactly: 60 kN total, 30 kN at each base.

The base moments are zero by definition — that is what “pinned” means, and the solver returns 0 kN·m, which is zero to within rounding.

Now the interesting part. The rafter wants to sag; because its ends are rigidly joinedto the columns, it cannot sag without bending them outward. The columns push back, and that push is a real horizontal reaction at each base — the thrust:

Horizontal equilibrium is still satisfied: the two thrusts are equal and opposite, so they sum to zero. But neither one is obtainable from alone — that equation only says they cancel, not how big they are. Their magnitude depends on the relative stiffness of rafter and columns, which is exactly the information statics throws away and the stiffness method keeps.

This is the whole difference between a frame and a truss. Replace the rigid joints with pins and the thrust vanishes: the rafter simply sags and the columns carry nothing but axial load.

Turn on the deformed shape. Under symmetric gravity load the portal should deflect symmetrically: the rafter sags, both eaves move slightly inward, and there is no sideways sway at all.

If your deflected shape leans to one side, something is wrong with the model rather than the structure — most often a support entered on the wrong node, or a load applied to one member when it was meant for another. The deflected shape is the fastest error check available, and it costs one click.

Statics fixes three of the four quantities below outright; the fourth — the thrust — is the indeterminate one, and it is reported here as the solver’s own result rather than checked against a hand value, because there is no hand value to check it against without carrying out the full flexibility calculation.