Computational Engineering / Digital engineering workflows
Versions, naming and the handover note
The unglamorous half of the subject, and the half that actually fails.
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
Record which model was analysed, when it was issued, which inputs it contained and how it was checked. Without that information, a later reviewer may be unable to connect a result with the structure and design situation it describes.
By the end of this lesson you should be able to
- Say why 'the current model' is not a version
- Write a handover note that lists what was NOT sent
- Design a naming convention that survives being used by other people
- Explain what makes a model reproducible a year later
'The current model' is not a version
On a shared environment the model changes continuously and without announcement. An analysis recorded as having been run against 'the current model on 14 March' cannot be reproduced, because there is no way to establish which state that was.
Identify the model with an immutable reference: a version number issued by the environment, or an exported copy saved at the time of analysis and kept with the results.
The handover note
A handover note is usually written as a description of what is being sent. It is more useful written as a description of what is not.
A note that says 'attached is the analysis model' tells the recipient nothing they could not see. A note that says the following is doing real work:
- Supports are not carried by this route. The model was analysed with a pin at gridline 1 and a roller at gridline 5.
- Releases are not carried. All beam-to-column connections were modelled as rigid.
- Loads are not carried. The model was analysed under the combinations in calculation sheet 4.
- Results, if included, identify their analysis revision, load cases, units and conventions. State what further checking or reanalysis the recipient must perform.
- The model is version 7, exported 14 March, from the analysis in calculation sheet 4.
That note takes five minutes and converts an invented model into a checkable one.
Naming
A naming convention has one job: to let somebody who was not there find the right thing. Three properties matter, and they are all unglamorous.
It sorts correctly. Dates as YYYY-MM-DD; numbers zero-padded. Rev2 sorting before Rev10 has cost more time than it should have.
It carries the discriminating fact. Whatever varies between the files is what the name must contain. If four files differ by load case, the load case belongs in the name, not in a folder somebody will flatten.
It survives other people. A convention only you understand is not a convention. The test is whether somebody who has never seen it can pick the right file on their first attempt.
Reproducibility
A model is reproducible if somebody else can obtain the same numbers from it a year later. That needs five things recorded, and they are the same five whatever the software:
- 1.The model, at an identified version
- 2.The software, at an identified version
- 3.The inputs — loads, combinations, material properties — and where each came from
- 4.The assumptions, particularly the ones that were choices rather than data
- 5.The checks that were run, and what they gave
Module 13 turns this into a model record and a review process. It is worth noticing how much of it is already necessary just to make a handover work.
Worked example
Reconstructing an analysis eighteen months later
Given
- A query arrives about a beam on a completed project
- The model file is found, and it opens
- There is no model record, and three model files exist with similar names
Find
What can and cannot be established
Practice
In a hypothetical exercise, five missing attributes are guessed independently. Each guess has a 30% probability of differing from the intended value. What percentage of cases have all five guesses correct?
Practice
Files are named Rev1, Rev2, ... Rev12. How many of the twelve sort into the wrong position under a plain alphabetical sort?
Check yourself
What makes a handover note useful, rather than a formality?
Practice
Files are named Rev01 to Rev12 with zero padding. How many sort into the wrong position alphabetically?
Check yourself
What makes a model reproducible a year later?
Check yourself
A shared model environment issues no version numbers. What is the workable answer?
Check yourself
What is the strongest test of a naming convention?
Summary
- 'The current model' is not a version — an immutable reference is
- A handover note earns its place by listing what was NOT sent
- A naming convention must sort correctly, carry the discriminating fact, and survive other people
- Reproducibility needs the model, the software, the inputs, the assumptions and the checks
- A model that is right but unidentifiable is not usable