Service overview
Mathematical modelling, numerical methods, multiphysics, uncertainty analysis and digital twins. This service is part of that division and is scoped individually around what you need to learn, decide or publish.
Simulation lets engineers evaluate designs, explore operating conditions and investigate failures without building every variant. It is also easy to misuse. A model can be assembled from default settings, give impressive visualisations and bear little relation to reality. Good simulation practice treats the model as a hypothesis whose credibility must be earned through careful definition, checking and comparison.
This service supports analysis of engineering components and systems from problem definition to interpretation. It is deliberately general: it covers the cross-cutting skills of defining the question, simplifying wisely, deriving loads and boundary conditions, checking sensitivity and presenting results with an honest account of what the simulation can and cannot represent. Domain-specific services such as CFD and finite element analysis build on the same foundations.
If you plan to publish the outcome, see manuscript & publication support, for example computational & simulation manuscripts or original research article writing.
What this service covers
Problems this service can address
- No clear link between simulation outputs and design decisions
- Boundary and loading conditions that are guessed
- Results presented without validation or sensitivity evidence
Methods and analytical approaches
- Model definition and simplification
- Boundary-condition and load derivation
- Mesh and time-step sensitivity
- Post-processing and comparison with reference data
Applications
- Design evaluation and comparison
- Failure investigation support
- Supporting data for manuscripts
Relevant engineering disciplines
Scope, inputs and deliverables
Scope of work
- Definition of the physics, geometry and quantities of interest
- Model set-up with verification and, where data allow, validation
- Parametric or sensitivity studies agreed at scoping
- Results and documentation suitable for reports or publication
- Feasibility check on: geometry or sketches and material data
Typical inputs required from you
- Geometry or sketches and material data
- Operating conditions
- Reference measurements, if any
Deliverables
- Simulation report with assumptions
- Result plots and tables
- Validation or sensitivity summary
Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.
Project workflow and method
- 01Enquiry and requirement assessment
- 02Technical scoping and proposal
- 03Execution
- 04Quality review and delivery, with an agreed round of revisions
Read the full project workflow.
In depth: how the work is done
Defining the problem and the model scope
Before any software is opened, we define what decision or insight the simulation should support and which outputs matter. This determines the physics to include, the level of geometric detail, the dimensionality, the time horizon and the accuracy needed. Features that do not influence the quantity of interest are simplified or removed, and each simplification is recorded. A model that is too detailed is slow and hard to validate; one that is too crude misses the effect of interest.
Boundary conditions, loads and material data
The results of a simulation are only as good as the conditions applied to it. We help derive boundary conditions and loads from measurements, standards or system-level models, check that they are physically consistent and examine how sensitive results are to their uncertainty. Material and property data are taken from documented sources with attention to temperature, rate and variability. Where inputs are uncertain, ranges and bounding cases are used instead of single guesses.
Mesh, time step and numerical sensitivity
Results must not depend materially on mesh density or time step. Systematic refinement in the regions that matter, and in time, quantifies the numerical error. Solver settings, convergence criteria and the treatment of nonlinearity are documented. Sensitivity to modelling choices, such as contact definitions, turbulence models or element types, is tested for the quantities of interest, and the spread is reported as part of the uncertainty.
Post-processing and comparison with reference data
Post-processing converts fields into engineering quantities, such as forces, temperatures, factors of safety or efficiency, and checks them against independent estimates, hand calculations, published benchmarks or experiments. Differences are examined quantitatively. We present results with units and uncertainty, avoid visual effects that exaggerate small differences and state clearly where the model is not expected to be reliable.
Handling design comparison and parametric studies
Simulation is often used to compare alternatives or explore a parameter range. We plan the study so that comparisons are fair, with the same boundary conditions, mesh strategy and convergence criteria for every variant, and with parameter ranges chosen to cover realistic conditions. Results are organised to show trends and thresholds, not just individual cases, and differences smaller than the numerical or input uncertainty are reported as not distinguishable. This prevents conclusions from resting on noise.
Quality control and good practice
Quality-control approach
- Verification: mesh, time-step and solver sensitivity are examined before results are reported.
- Validation: results are compared with measurements or reference solutions where these exist, and the absence of such data is stated.
- Boundary conditions and material or fluid properties are recorded with their sources.
- Sensitivity to the least certain inputs is shown or explained.
Common pitfalls this service helps avoid
- Believing colourful plots. Contour plots look authoritative even when the model is poorly converged or incorrectly constrained.
- Unrealistic boundary conditions. Idealised supports, loads or flows can dominate the answer and misrepresent the real system.
- Single-case conclusions. Results from one configuration may not generalise; parametric variation shows trends.
- Skipping independent checks. Without hand estimates or benchmarks, gross errors can pass unnoticed.
What good reporting looks like
A simulation report states the objective, the model and its assumptions, inputs with sources, boundary conditions, numerical settings, convergence and sensitivity studies, results with units and uncertainty, comparison with reference data and limitations. It records software and version information so that the work can be repeated. It distinguishes what the simulation shows from what is interpretation, and it does not claim performance beyond the validated range.
An illustrative scenario
Hypothetical example written for explanation. It is not a client case, a result or a testimonial.
Suppose an engineer wants to compare two bracket designs under service loads. The initial model fixes one face rigidly and applies a single static load. A review notes that the real mounting is bolted and the load varies. The revised model represents bolt preload and contact, uses two load cases, and shows that stress concentrations differ between designs by a margin larger than the mesh sensitivity. A hand calculation supports the nominal stress level, and the report recommends a fatigue-oriented test before design selection.
Questions to settle before you begin
- What decision will the simulation support?
- Which loads and boundary conditions are known, and which are assumptions?
- How will I test mesh and time-step sensitivity?
- What independent check, such as hand calculation or experiment, is available?
- What would make me distrust the result?
Key terms
- Quantity of interest
- The output the simulation is meant to predict.
- Boundary condition
- A condition specifying behaviour at the edge of the model domain.
- Mesh sensitivity
- Change in results as the mesh is refined.
- Bounding case
- An analysis using extreme but plausible inputs to bracket the result.
- Benchmark
- A reference problem with known or well-accepted results.
Working together on Computational Engineering & Modelling projects
Computational engagements begin by agreeing the question, the quantities of interest and the accuracy that matters, so that modelling effort goes where it changes the answer. We ask for geometry or system descriptions, operating conditions, material or property data and any measurements for validation. Early on, a small pilot case often checks feasibility and cost. Models are verified and, where data allow, validated before parametric results are produced. Software, versions and settings are recorded so results can be reproduced. Where inputs are missing, assumptions are listed and agreed rather than quietly filled in.
Frequently asked questions
Which type of simulation do I need?
It depends on the dominant physics: fluid flow, solid mechanics, heat transfer, or coupling of these. During scoping we identify the minimum model that can answer your question.
Which software do you use?
The choice depends on the problem, your licences and reproducibility needs, and is agreed at scoping.
Can you simulate from a CAD file or drawing?
Yes, provided the geometry and operating conditions are sufficiently defined. Missing information will be listed and assumptions agreed.
How do you know the simulation is right?
By verification, sensitivity studies and comparison with independent data or benchmarks. Where none exist, results are labelled as unvalidated.
Can simulation replace testing?
It can reduce the number of tests and explore cases that testing cannot, but validation against experiments remains important for critical conclusions.
How is this service scoped and priced?
After your enquiry we review what you need, ask for missing information and send a written scope and quotation. Price depends on complexity, deliverables and timeline. See the project workflow.