P-Delta Analysis and Out-of-Plane Instability in MasterPort and MasterFrame
ELI5 summary
A P-Delta analysis checks what happens when a frame deflects and the loads continue to act on the deflected shape. This can magnify moments and sometimes expose an instability that is not obvious in a normal first-order analysis.
In a real portal building, members such as rafters, columns, crane stubs, purlins, side rails and runway beams are often restrained by surrounding steelwork. If those restraints are not included in the analysis model, the software may see a member or part of the frame as being free to move or buckle out of plane. The result may be a failure to converge or an instability warning during the P-Delta analysis.
In simple terms: the software may be analysing a “bare frame” which is much less restrained than the real building.
Why this can happen
P-Delta analysis is sensitive to stiffness, restraint and member connectivity. If a member is free to move laterally or rotate without sufficient restraint, the second-order analysis may amplify that movement as the load is applied. In nonlinear iterations, this can appear as the member drifting, twisting or buckling progressively until the analysis cannot find a stable solution.
This does not always mean the whole portal frame is unstable. It may instead indicate that the analytical model is missing a restraint or stiffness path that would exist in the real structure.
Common examples include:
- A crane column stub modelled as a cantilever from the main portal column, with no runway beam or restraint modelled at its outer end.
- A portal rafter analysed without purlins or lateral restraints explicitly included in the analysis model.
- A side rail, purlin, canopy, parapet or secondary member included as a real member but left unrestrained out of plane.
- A member with releases or connectivity that make it unstable under second-order analysis.
- A model where the global frame is stable, but a local secondary element is not restrained in the analysis.
MasterPort behaviour
In MasterPort, the simplified interface represents the primary portal frame and uses purlin/side-rail positions for steel design restraint checks. However, those purlins and side rails may not always be explicitly modelled as analytical members providing restraint during a P-Delta analysis.
Therefore, if the P-Delta iterations show rafters deflecting or buckling out of plane, it may be because the model is effectively analysing the primary members without the restraint that would be provided by the purlin/rail system in the real structure. Read more 📄 P-Delta Instability in Portal Frames
A similar issue can occur with crane stubs. The Cranes tab can create column stubs to support runway beams, but if the stub behaves analytically like a cantilever with an unrestrained end, P-Delta analysis may detect a local instability at the stub/column arrangement. If removing the stubs allows the model to converge, this is a strong indication that the instability is associated with the local stub arrangement rather than the main portal frame alone.
Increasing the main column size may fix the issue because it increases the local stiffness at the stub support and reduces second-order movement providing a stiffer supporting column gives the cantilevered stub less opportunity to amplify movement under P-Delta.
MasterFrame behaviour
MasterFrame is a general space-frame analysis program. It analyses the model as entered. Unlike MasterPort’s ability to model the effect of out-of-plane restraint within the simplified interface, MasterFrame does not automatically assume that purlins, side rails, cladding or secondary framing provide restraint unless those restraints or members are explicitly included in the analytical model.
For MasterFrame P-Delta analysis, the user should understand that the analytical model contains the restraints needed to represent the intended real behaviour. This may include modelling purlins, side rails, runway beams, bracing, diaphragm restraints, or appropriate nodal restraints, depending on the design assumption.
Elastic versus plastic P-Delta
Elastic P-Delta and plastic P-Delta can behave differently.
- In an elastic P-Delta analysis, the members retain their elastic stiffness throughout the run. This may allow the analysis to converge, even if the model is relatively flexible.
- In a plastic P-Delta analysis, plastic hinges may form and local stiffness is reduced. If hinge formation occurs near an already flexible or poorly restrained region, the model can become unstable more easily. This is why a model may pass elastic P-Delta but fail plastic P-Delta.
This is particularly relevant where crane stubs, rafter haunches, or other local elements are close to their plastic capacity. Once stiffness is reduced, the P-Delta effect can magnify movement and prevent convergence.
Common locations to check
Crane column stubs
Crane stubs can behave like short cantilevers if their outer end is not restrained by a runway beam or other framing. If the P-Delta analysis fails only when the crane stubs are included, review the stub connectivity, releases, eccentricities, and whether the runway beam/restraint system should be represented in the model.
Portal rafters without purlin restraint
A bare rafter may appear to move or buckle out of plane during P-Delta iterations if the purlins are not modelled or if lateral restraints are not represented analytically. In the real building, purlins and roof bracing may restrain this behaviour, but the analysis model must contain an appropriate representation of that restraint if it is required for stability in the P-Delta run.
Canopies and parapets
Canopies and parapets can be relatively flexible appendages to the main frame. If they are included as analytical members and not restrained adequately, they may govern the instability even though they are not part of the main sway-resisting system.
P-Delta Instability in Portal Frames (Purlins and Side Rails)
It is very common to experience P-Delta instability in a Portal frame, having been able to successfully perform a first order elastic analysis. In many instances this is due to how the effects of the portal frame purlins and side rails are considered (or not at all) in the model.
Typically in portal frame modelling, purlins and side rails are not included in the structural model as they do not affect the in-plane behaviour of the portal frame in terms of the in-plane member forces generated. The lateral restraining effects of the purlins and side rails are then accounted for at post analysis design stage, when considering buckling effects.
P-Delta can capture out of plane buckling behaviour, hence the lack of the restraining effect of these purlins/side rails can cause second order P-Delta stabilities.
Following a failed P-Delta with 'Newton Raphson' method, going to 'Results> Nonlinear iteration viewer' to inspect the deformation in each iteration gives a good indication as to the second order instability.
In this example you can see many of the rafters deflecting and buckling as the iterations progress. Clearly this would not happen with the purlins in place.
Typically the solution is to model members along the lines of roof bracing intersection points to provide this stability, rather than modelling members at every purlin. These member should have
- 'UT Ignore Self Weight'.
- Ends released
- a section size suitable to transfer the axial force to provide the stability.

Typically it's the rafters that require this consideration for a successful P-Delta and rarely are the side rails required to be modelled for the columns, however a similar approach could be used if required.
More generally, considering even the elastic analysis for wind loading on the gable frames, these additional roof 'purlin' member perform the function of sharing load across any distinct roof bracing systems.
MasterPort Plus 3D Portal frame generation automatically creates these roof 'purlin' members at bring intersection points.
See also:
- 📄 Modelling the Real World Effects of Roof Cladding on a Portal Frame
- 📄 Are Purlins Considered in the Frame Analysis?
Recommended diagnostic workflow
- First, run the model without P-Delta to confirm the first-order model is stable and the load paths are broadly as expected.
- Then run elastic P-Delta and review whether the instability appears. If the elastic P-Delta run passes but the plastic P-Delta run fails, the issue may be linked to hinge formation and loss of stiffness.
- Use the Nonlinear Iteration Viewer to inspect the deformed shape as the analysis progresses. Look for the first region that moves excessively, buckles, rotates or distorts. This is often more useful than looking only at the final error message.
- Temporarily remove or isolate secondary elements such as crane stubs, canopies, parapets, or roof transfer members to determine whether the instability is global or local.
- If removing a particular element allows the model to pass, review whether that element is missing a restraint that exists in the real structure.
- Check member releases, support fixities, eccentricities and load application points.
- Where relevant, add the restraint system explicitly, such as runway beams, purlins, side rails, bracing members or nodal restraints, rather than relying on a design-time restraint assumption.
Possible modelling approaches
Where the main portal frame needs to be checked for second-order global effects, it may be appropriate to design the main portal with P-Delta enabled, ensuring that the global sway behaviour is captured.
If a local secondary element such as a crane stub is creating a local P-Delta instability because the full restraint system is not represented, one option is to check the main portal frame with P-Delta on, then carry out a separate local check/design of the crane stub with P-Delta off, provided this is consistent with the engineer’s intended design assumptions and the stub is not part of the global stability system.
The correct approach depends on whether the member in question is part of the global stability system or is a local secondary element.
Key message for users
A P-Delta instability warning does not always mean the whole portal frame is fundamentally unstable. It may mean that the model contains a member or sub-system which is not restrained in the way it would be in the real structure.
The engineer should review the deformed shape, identify the location of the instability, and decide whether the model needs additional restraint, different member releases, a stiffer section, or a separate local design approach.
MasterSeries can help identify where the instability is occurring, but the final modelling assumption should be consistent with the intended structural behaviour and the real restraint details.