Module 1 · Lesson 1.1
The computer as engineering assistant
What computation does well, what it does badly, and why the division of labour matters more than the tool.
Why this matters
Every structural engineer now works through a computer. That is not a claim about software; it is a claim about where the answers come from. The bending moment you design to was computed by something you did not write, from a model you did build, using assumptions that may or may not still be in your head.
This course is about the part you build and the assumptions you carry. It is not about how solvers work internally — that is Module 9, and only enough of it to model well. It is about the judgement that sits between an engineering question and a computational answer, because that judgement is the whole of what an engineer contributes and the only part a computer cannot take over.
By the end of this lesson you should be able to
- Name what computation genuinely adds
- Name what it cannot add, precisely rather than vaguely
- Explain 'garbage in, garbage out' as a statement about responsibility
- Distinguish precision, accuracy and usefulness
What computation adds
Six things, and it is worth being exact about them because each has a different failure mode.
Scale. A frame with 40,000 elements is not a harder problem than one with four; it is the same problem, forty thousand times. Computation removes the labour, not the difficulty.
Repetition. Two hundred load combinations, checked identically. A human doing this makes different mistakes each time; a computer makes the same mistake two hundred times, which is at least detectable.
Exploration. Twenty schemes compared in the time one used to take. This is the change that has altered practice most, and Modules 14 to 17 are about it.
Problems with no closed form. An irregular slab with three openings has no formula. Before finite elements, engineers either found a structure that did have a formula or accepted a crude approximation.
Simulation. Watching a structure respond over time — to an earthquake, a blast, a construction sequence — rather than at one instant.
Communication. A model that several disciplines can work from, and a record of what was designed.
What it does not add
Understanding. The solver does not know that the thing it is analysing is a building. It does not know that a 40 mm deflection over a 6 m span is absurd, that steel does not have a modulus of 210 Pa, or that a load pointing upwards is unusual. Every one of those has reached a design.
Judgement about what to model. The most consequential decisions — what to include, what to leave out, which behaviours matter — are made before the software is opened, and no software makes them.
Responsibility. This is not a philosophical point. The engineer who seals the drawing is answerable for the analysis behind it, including the parts nobody looked at.
Garbage in, garbage out
The phrase is older than structural software and it is usually quoted as a warning about input errors. That is the smaller half of it. The larger half is that the output looks identical either way. A wrong model produces neatly formatted results, plausible colour contours, and a converged solution. Nothing in the presentation distinguishes it from a right one.
That is why this course spends five modules on checking. It is not because checking is virtuous. It is because there is no other signal.
Three things that look like evidence and are not
Convergence. A nonlinear solver that converges has found a state satisfying equilibrium — for the model it was given. If the supports are wrong, it converges beautifully on the wrong structure. Module 12 has a case built precisely around this.
No warnings. Software warns about things its authors anticipated. The most dangerous errors are the ones that produce a clean run: a pressure applied inwards, a diaphragm that also restrains vertically, a member silently dropped in an import. All three appear later in this course and all three run without complaint.
A plausible picture. Contour plots are smoothed for presentation. Deflected shapes are magnified by whatever factor makes them visible. Both are designed to look reasonable, which makes them poor evidence that anything is.
Check yourself
A nonlinear analysis of a transfer structure converges in four iterations per load step with a tight residual tolerance and produces no warnings. What has been established?
Worked example
Does this need a computer at all?
Given
- A single simply supported beam, 7 m span, uniform load
- The question is whether a 406 × 178 × 60 UB is deep enough for deflection
- A model would take about forty minutes to build and check
Find
Whether to model it
Worked example
What a computer is actually good at
Given
- Two tasks: solving a 5 000-equation system, and deciding whether a support is really pinned
Find
Which is the computer's and which is the engineer's, and why
Practice
A hand calculation takes 2 minutes and a model takes 40 minutes to build. Above how many repetitions of the same calculation does the model become quicker, ignoring the time to run it?
Check yourself
What is the strongest argument for building a model rather than calculating by hand?
Check yourself
Which of these is a task a computer cannot take over?
Check yourself
An engineer says 'the software does the analysis, so I only need to check the output'. What is wrong with that?
Check yourself
Why is 'the computer got it wrong' almost always the wrong description of a failure?
Summary
- Computation adds scale, repetition, exploration, reach, simulation and a shared record
- It does not add understanding, judgement about what to model, or responsibility
- The output of a wrong model is indistinguishable in presentation from the output of a right one
- Convergence, silence and a plausible picture are not evidence
- Two significant figures is about the honest limit for a structural result
This is educational material. It uses simplified examples to teach principles, and must not be relied on for real design or safety-critical decisions. Module overview and checkpoint