Computational Engineering / Digital engineering workflows
The chain of handovers
What a workflow actually is, what each step adds, and the five things nothing carries.
Lesson review: expert verification remains open
This lesson has received a full-context editorial review and a check of its technical explanations. Selected arithmetic has been checked separately. This is not independent engineering sign-off.
Checks needed for project use
- A computational engineering reviewer must check algorithms, convergence claims, statistical assumptions and numerical examples beyond the cases explicitly recorded.
- Verify the lab exchange-capability tables against each actual exporter/importer before presenting them as real software behaviour.
- Check truss load-loss and force examples against the complete model; independent arithmetic here checks scaling laws and counts only.
These are educational models and exercises. Check their assumptions before using the results. The full technical content and every diagram have not yet been independently verified.
Concrete and steel calculations retain their stated first-generation Eurocode teaching basis. Use the standards and amendments specified for your project; do not mix generations without an appropriate design basis.
Read the lesson register and outstanding review notesWhy this matters
A structural workflow passes information between people and models. Each transfer needs a defined purpose, an agreed set of information and a check of what arrived. Reviewing these handovers helps identify losses that may remain hidden in an otherwise plausible model.
By the end of this lesson you should be able to
- Describe a workflow as handovers rather than as tools
- Say what each handover adds that did not exist upstream
- Identify who owns a handover, as distinct from who performs it
- Name the attributes that survive no handover in the chain
What you should already know
- Module 3's parametric model — the second box in the chain
- Module 4's scripting — most handovers are automated by somebody
Models and handovers
A project may use architectural, parametric, analysis, coordination and fabrication models. Their purposes and contents overlap, but they need not contain the same information. Identify the model, revision and intended use when requesting or supplying data.
Moving from geometry to analysis often adds restraints, releases, sections, materials and loads. Member design may add effective lengths, combinations and design criteria; fabrication adds connection and manufacturing details. Some handovers add decisions, while others transfer existing information.
Agree what will be carried
Whether supports, releases, load cases, combinations or results survive depends on the schema, export settings and receiving implementation. Structural exchange schemas can represent these concepts; a geometry-only route may not. Verify the specific transfer rather than assuming either complete preservation or complete loss.
For the simplified workflow exercise, inspect the capability table and treat its losses as assumptions of that exercise. They are not universal properties of all formats.
Results may be exchanged when they are traceable to the model, revision, units, conventions, load cases and analysis settings that produced them. A force schedule without that context is insufficient. Reanalyse or independently check results to the extent required by the receiving task; do not silently treat old results as current.
Responsibility for the handover
Agree who prepares the export, checks the received information and resolves discrepancies. Record information omitted by the route and how it will be supplied or established. Missing assumptions should be clarified, not invented.
Choose the exchange route according to what the receiving model needs to do. A coordinate table can include structural attributes if its columns and conventions are defined. An object or fabrication format may carry useful detail but still require additional analysis information. Native files also need version and compatibility checks.
Try it
Digital workflow builder
One handover at a time. What arrives, what does not, and who owns the gap.
1 of 5
Before revealing, decide for yourself which of the twelve attributes this route carries.
Architectural model → Parametric model
- Exchange route
- Geometry interchange (lines and points)
- Owned by
- Structural lead
- Adds
- Grid, levels, and the decision about what is structure.
Twelve attributes go into this handover. Decide which arrive before revealing.
Across the whole chain
- Attributes surviving no handover
- 5
These are re-created by a person every time
- Supports and restraints
- End releases
- Load cases
- Load combinations
- Analysis results
What this shows: Every handover adds engineering judgement, loses information, and belongs to somebody — and five attributes survive none of them.
Worked example
What a coordinate table actually carries
Given
- A truss is passed to a checking engineer as a spreadsheet of node coordinates and member ends
- The sender's model had pinned supports at one end, a roller at the other, and 4000 mm² chords
- The receiving engineer builds an analysis model from the table
Find
Which of the twelve model attributes reached the receiving engineer
Practice
A workflow has five handovers. If each one is performed correctly 95 % of the time, and the errors are independent, what percentage of the time does a model reach the end of the chain with no handover error at all?
Practice
In the simplified five-step workflow exercise, how many listed attribute categories are marked as lost or degraded across the chain?
Check yourself
An analysis model is exported to a coordination model, and the end releases are lost. Is this a problem?
Worked example
Who owns the handover nobody set up
Given
- A parametric model is exported to analysis by a graduate, using a script written by a colleague who has left
- The script was never documented and has been used on four projects
Find
Who owns this handover
Practice
A chain of four handovers is each performed correctly 98 % of the time. What percentage of models reach the end with no handover error?
Practice
Of the twelve model attributes, a coordinate table carries two intact and loses six outright. How many does it degrade?
Check yourself
Why is 'the model' a phrase worth distrusting on a project?
Check yourself
What do the development steps in the illustrated workflow often add?
Check yourself
Why should analysis results be accompanied by their model and analysis context?
Check yourself
A format carries geometry perfectly and no structural properties. What makes that combination dangerous rather than merely limited?
Summary
- A workflow is a chain of handovers, not a list of software
- A handover may add decisions or transfer existing information; state which occurs
- Ownership is who would be asked to explain it, not who ran the export
- Check how the specific route handles restraints, releases, loads, combinations and results
- Exchange results with an identified analysis, conventions and checks appropriate to their intended use
- The right question is what the receiving model needs to do