Computational Engineering

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.

1. 01Enquiry and requirement assessment
2. 02Technical scoping and proposal
3. 03Execution
4. 04Quality review and delivery, with an agreed round of revisions

Read the full project workflow.

In depth: how the work is done

1. Formulating the problem

   Formulation chooses what to model and what to neglect. We start by defining the quantities of interest and the accuracy required, then select governing equations, domain, boundary and initial conditions and material or constitutive models. Simplifications, such as symmetry, two-dimensional representation or neglect of a weak effect, are justified by scaling arguments or preliminary estimates. Documenting the formulation exposes hidden assumptions that otherwise surface as unexplained discrepancies later.

2. Discretisation and convergence

   Continuous equations are approximated on a mesh, grid or set of basis functions. Solutions should converge towards a limit as the resolution increases, and convergence studies on a sequence of systematically refined meshes and time steps estimate the discretisation error. Where the observed order of convergence differs from the theoretical order of the scheme, it signals problems such as insufficient resolution, singularities or implementation errors. Solver tolerances and iterative convergence are monitored separately from discretisation.

3. Verification and validation planning

   Verification asks whether the equations are being solved correctly, using code checks, manufactured solutions, comparison with analytical results and grid convergence. Validation asks whether the right equations are being solved, using comparison with experimental data with known uncertainty. Planning validation early identifies which measurements are needed, how to define acceptance criteria and which discrepancies would indicate model-form error. When no validation data exist, that limitation is stated and the results are treated as exploratory.

4. Surrogates and reduced-order models

   High-fidelity simulations may take hours or days, which hinders parametric studies, optimisation and uncertainty analysis. Reduced-order models and surrogates, such as polynomial chaos, Gaussian process or projection-based models, approximate the full model at low cost within a range of parameters. Their construction requires careful sampling and validation against fresh high-fidelity runs, and their error is accounted for in any conclusion that relies on them.

5. Documenting computational work for reuse

   Computational results should be reproducible by the person who produced them six months later and by others. We recommend a directory structure for inputs, scripts and outputs, a record of software versions and compilers, parameter files that are version-controlled and a short readme that explains how to rerun key cases. Where code or data cannot be shared publicly, a clear statement of availability is prepared. This documentation also supports the data availability statements that many journals now require.

Common pitfalls this service helps avoid

• Trusting a single mesh. Without refinement studies the discretisation error is unknown and may exceed the effect being studied.
• Confusing convergence with correctness. A solution can converge nicely to the wrong answer if the model is physically inappropriate.
• Undocumented software settings. Defaults for solvers, turbulence or contact models can alter results and must be recorded.
• Using a surrogate outside its range. Reduced models are reliable only where they were trained and validated.

What good reporting looks like

A computational study report states the objective and quantities of interest, formulation and assumptions, numerical methods and software versions, mesh or discretisation details with convergence results, verification evidence, validation comparisons with uncertainty, parametric results and limitations. Input files or parameter tables are provided to support reproducibility. Conclusions are limited to the validated domain, and any extrapolation is flagged as such.

An illustrative scenario

Hypothetical example written for explanation. It is not a client case, a result or a testimonial.

Imagine a researcher modelling heat conduction through a composite with temperature-dependent properties. The first model runs and gives plausible plots. A review finds that only one mesh was used and the time step was chosen arbitrarily. Refinement studies show that the peak temperature changes by a notable amount between meshes, and a manufactured-solution test reveals an error in the treatment of a boundary condition. After correction, comparison with experimental thermocouple data supports the model within the combined uncertainty, and the report states the range of conditions covered.

Questions to settle before you begin

• What quantity do I need the computation to predict, and how accurately?
• Which physical effects can I safely neglect and why?
• How will I demonstrate convergence?
• What data will I use for validation, and what is its uncertainty?
• Which software versions and settings must be recorded?

Key terms

Discretisation

Approximating continuous equations on a mesh or finite set of basis functions.

Grid convergence

Behaviour of the solution as the mesh is refined.

Verification

Assessing that a computational model solves its equations correctly.

Validation

Assessing that a model represents the real system adequately.

Surrogate model

A fast approximation of a more expensive model.

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.

Few projects need a single service in isolation. These are the services most often combined with this one.

• Mathematical Modelling

  Formulation of mathematical models for engineering and physical systems: choosing state variables and governing relations, simplifying sensibly, and checking behaviour against limiting cases and data.

• Numerical Methods & Scientific Computing

  Selection, implementation review and verification of numerical schemes for differential and algebraic problems, including stability, accuracy and performance considerations.

• Engineering Simulation

  Simulation-based analysis of engineering components and systems, from problem definition and model set-up through post-processing and interpretation, with a clear account of what the simulation can and cannot represent.

• Multiphysics Modelling

  Coupled simulation of interacting physical phenomena, such as fluid-structure, thermal-structural, electro-thermal or thermo-chemical problems, where one-way or two-way coupling must be chosen deliberately.

• Sensitivity & Uncertainty Analysis

  Quantification of how input uncertainty and parameter variation propagate to outputs, identifying which inputs drive results and how confident conclusions can be.