CROSS Safety Report
Potentially unsafe buckling resistance checks using software
Overview
A reporter detected a number of anomalies in outputs from a proprietary structural steelwork design program.
Key Learning Outcomes
For civil and structural design engineers:
- Designers should understand the principles of the problem at hand (and design code) before using software
- Simple cross checking with published examples (validation), is highly encouraged before using software that the engineer is not familiar with
- Ensure any software models the structural elements as anticipated
- If you are concerned with any outputs, consider raising this with the software technical support team and seeking clarification
- It is good practice to carry out sense checks and validate all analysis and design outputs
Full Report
Find out more about the Full Report
The Full Report below has been submitted to CROSS and describes the reporter’s experience. The text has been edited for clarity and to ensure anonymity and confidentiality by removing any identifiable details. If you would like to know more about our secure reporting process or submit a report yourself, please visit the reporting to CROSS-UK page.
A reporter designing structural steelwork by way of a commonly used software package identified a number of anomalies. These concerned buckling checks on steel members subjected to applied axial forces and bending moments. The anomalies were:
- That the design code required the overall buckling check to be based upon the maximum moment, whereas the software called for the applied moment to be used in this check. The change in terminology is unhelpful and may lead to incorrect values being assigned.
- That within an overall buckling check, the forces and bending moments at a particular cross section were identified as the critical case, whereas the overall buckling check should have been based on the maximum forces and moments in the length under consideration.
- The incorrect calculation of an 'equivalent uniform moment factor' and therefore incorrect overall buckling check, for a frame with intermediate restraint in one axis of buckling only.
Recognising that the software did not provide expected outputs, the reporter drew a number of conclusions:
- Designers must understand the design code before using software.
- Designers should understand the design parameters and definitions in the design code as well as the same in the design software. Designers can then correlate the two, provide the correct inputs and recognise anomalies in outputs.
- The parameters set within the design program may not be the same as those expected by the designer.
- Simple cross checking with examples (validation), is highly encouraged before using software that the engineer is not familiar with.
- Design software should be used by competent engineers.
Submit a report
Your report will make a difference. It will help to create positive change and improve safety.
Our secure and confidential safety reporting system gives professionals the opportunity to share their experiences to help others.
Feedback
No feedback has yet been published for this page.
Expert Panel Comments
Expert Panels comment on the reports we receive. They use their experience to help you understand what can be learned from the reports. If you would like to know more, please visit the CROSS-UK Expert Panels page.
The reporter is to be congratulated for bringing their findings to light and for their conclusions, which are very sound, and likely arrived at through significant experience.
Software deficiencies are relatively rare but do happen. It is a pre-requisite for using software that the user must be able to recognise incorrect or unexpected situations and outputs. Simply put, software should only be relied upon by those who know what the answers should be, otherwise, they will not recognise errors in the software or more likely, errors in the use of the software. Where errors in commercially available software are found, suppliers should be challenged to demonstrate their validation and calibration of the software.
A starting point in any design should be that designers understand the structural principles and then make appropriate models for a computer to do the arithmetic. In steelwork design, unless the designer understands member end restraints (via connections of their choice) the answer will come out wrong.
Digital tools can be very good at manipulating data, but design and analysis are always an idealisation of a structure and not 'digital perfection'! It is important to recognise that digital models are good at showing what exists in a design, but they may not be representative of a real structure. They probably will not contain the uncertainties of tolerances of construction and may not model connection stiffness well - models can be a further step away from reality.
digital models are good at showing what exists in a design, but they may not be representative of a real structure
It is crucial that younger engineers develop a feel for what is right and wrong such that they too can enjoy passing their wisdom on. Less experienced engineers will benefit from deriving and repeating some computer calculations (for example capacity checks) by hand so they know exactly what the basis of the check is and to make sure the inputs and outputs match the hand check.
Computer aided design, irrespective of which design code is applied, is an essential part of structural design, but it must be remembered that the software is only an aid to the designer. The design organisation must fully understand and validate all outputs. This requires engineers who are sufficiently competent to understand the software presumptions and outputs. The importance of validation in software use is noted in the Institution of Civil Engineers publication - The importance of understanding computer analyses in civil engineering.
Previous CROSS reports of interest include Computer aided design concerning column design and Unconservative design of flat slab due to software modelling issues which also references the thought-provoking SCOSS Topic Paper Reflective Thinking.