Piling It On: Engineering Calculations Today

When it comes to doing calculations, I believe we are a profession in crisis. Let me relate a common story. On an onshore oil refinery project, I was asked to check a calculation that was long overdue for a wide operators’ platform supported on three buried vessels. In essence, the platform is a continuous beam over multiple supports and lots of point loads for grating dead and live loads. I had a picture in my mind of what to expect: perhaps, two pages describing the platform, a general arrangement plan of beams, loading and vendor information, followed by a sketch layout for the designer. There might be an additional two pages of simple numbers to confirm beam sizes. My effort would equate to checking a calculation in the range of seven to 10 pages — all in a morning’s work. What I actually received was closer to 250 pages analyzing 242 possible load combinations, a document that took the engineer three months, with overtime, to prepare. The design was not ultimately flawed, the calculation was accepted, without change, and the engineer thought his work was a progressive piece of engineering. I know this is the tip of the iceberg. It gives me a sense of engineering walking backwards.

Engineering calculations are a legal and practical requirement for any structural engineering project. They record the design assumptions, establish the basis for design and demonstrate its adequacy. The documents are subjected to scrutiny and verification by a third party before the design is approved.

Within the oil and gas industry, with which I have been involved for over 20 years, there has been a sea change in the way we work, where we work, and how we work. Many of us are familiar with the changes. From an environment of smoky, noisy halls, stand-up drawing boards and hand power, we have moved to silent office space, cubicles and screen power. I have experienced the generational changes and have seen how we are losing our craft.

Crucially, in a world of high expectations we have lost time to learn, think and talk to each other about our common tools. Consequently, I find that engineers do not challenge the go-by or hand-me-down examples, or seek to improve upon the agreed design concept established by others. On large projects, change is frowned upon and engineers are not encouraged to go against the grain. It takes a special engineer, with confidence, to challenge it.

And today, the chances are high that calculations are not concise or simplified; they are voluminous, detailed and address every component of the design without identifying the critical behaviour.

Checking another engineers’ calculations is requiring more and more time and resources. I see fundamental steps overlooked, steps such as:

-identifying the critical load path -identifying the critical load combination

-assumptions of the design, such as support conditions, joint behaviour, etc.

Explaining these aspects in simple terms as positive declarative statements would help the checker. They are not intuitive but critical statements that form the core of the calculations. It would be helpful, for example, to know that a tension bracing and its connection is the most critical part of the pipe rack design at 650 kN; or to read that a total of 300 kN of wind is applied to the structure. I have used simple numbers but you will see 298.465 kN or 3.02332E+05 N. Try to remember them in 20 minutes time! I receive calculations lacking in these summaries and simple numbers and am expected to approve them.

What happened to us?

The last 15 years has seen a strait-jacket mentality evolve in the way civil/ structural engineers work in the design office. The emergence of desktop computers has ironically killed the engineer’s ability to interact with the technology and produce calculations effectively.

Up to the time of the supremacy of the desktop, mainframe computers were designed, programmed and managed by engineers. The languages of FORTRAN, Basic and COBOL ruled the world. The on-screen data was not pretty –graphical charts were a ghastly series of Xs! But the technology worked. More importantly, engineers were formally trained to master the programming.

Desktop computer technology and Windows smashed that. Like those in the proverbial Tower of Babel, we lost the computer technology plot; it was taken out of our hands. The computer languages proliferated into Pascal, C+, VB, Java and we saw the dawn of the modern computer profession.

When the programming was step-by-step in machine code, many engineers produced flowcharts and documentation to explain their logic and assumptions. Structural engineering calculations produced by hand were concise and simplified; they identified and addressed the key elements of the design. But with the desktop computer,

———

CHANGING THE WAY WE WORK

To break the mould, engineers need to look at the way they work:

• Brainstorm the details together

• Talk to each other and don’t work in isolation

• Identify, agree and focus on the key component of the design

• Break the work into smaller components (e. g. reactions, concrete and structural steel)

• Perform more frequent regular checks

• Use more illustrations, drive the calculations visually

• Use proforma templates

• Go forward in time, do not recycle work for small changes

• Do not keep a history of superseded pages in the calculations

• Design the calculations for the reader/checker and save their time

• Use simple numbers

• Summarize the major loads and material take-offs

• Remember that the sequence of work is not the same as the sequence of the calculations

• Avoid automatically performing 3D analysis

• Use the structural analysis to verify the thinking

• Ensure the calculations are an active document in the engineering design cycle

• Leave the analysis towards the end of the design cycle

• Remember that the calculations are a minimum basis for design, not the final