Numerical Methods & Scientific Computing

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. Choosing a discretisation

   Finite-difference methods are simple on structured grids; finite-volume methods enforce conservation locally and suit transport problems; finite-element methods handle complex geometries and variational formulations; spectral and other high-order methods offer rapid convergence for smooth solutions. The choice depends on the physics, geometry, smoothness of the solution and conservation requirements. We discuss the trade-offs of accuracy, robustness and implementation effort and recommend a scheme in light of your objectives.

2. Stability, consistency and convergence

   A scheme should be consistent with the continuous equation, stable so that errors do not grow without bound, and therefore convergent. Stability analysis, such as von Neumann analysis for linear problems, and conditions such as Courant-type limits for explicit schemes, determine permissible time steps. Stiff problems require implicit or specially designed integrators. We check whether stability limits are respected and whether artificial dissipation or limiting used for robustness degrades the accuracy that matters.

3. Solvers for algebraic systems

   Discretisation often leads to large sparse linear or nonlinear systems whose solution dominates computing cost. Direct solvers are robust but memory-hungry; iterative Krylov methods with preconditioning scale better but depend on problem structure. Nonlinear systems use Newton-type methods, requiring good initial guesses and careful Jacobian treatment. Convergence criteria and residual monitoring are specified and reported, since loose tolerances can masquerade as physical behaviour.

4. Code verification with manufactured solutions

   The method of manufactured solutions chooses an analytical function, substitutes it into the equations to derive a source term and then checks that the code reproduces the function with the expected order of convergence as the mesh is refined. This isolates implementation errors from model errors and is far more discriminating than eyeballing results. Additional tests include conservation checks, symmetry tests, comparison with known analytical solutions and regression tests to protect against later changes.

5. Reporting algorithms in methods papers

   Methods papers carry a higher burden of proof. They should state the algorithm clearly, give pseudo-code or equations in sufficient detail to implement, specify test problems and metrics, and compare against appropriate existing methods under fair conditions. We help structure the numerical experiments, choose test cases that reveal strengths and weaknesses, and present convergence and cost results honestly, including cases where the proposed method does not perform well.

Common pitfalls this service helps avoid

• Reporting the nominal order of accuracy without testing. Implementation errors often reduce the observed order; only measurement shows what the code achieves.
• Excessive numerical diffusion. Stabilising techniques can smear features that carry the physics of interest.
• Loose solver tolerances. Unconverged iterative solutions can introduce errors larger than discretisation error.
• Comparing algorithms unfairly. Methods differ in cost per step, so comparisons should use equal accuracy or equal computing time.

What good reporting looks like

A numerical-methods report describes the equations, the scheme and its theoretical properties, the implementation, test problems with analytical or manufactured solutions, observed convergence rates, stability limits, solver settings and tolerances, computational cost and limitations. Where algorithms are compared, the criteria and test cases are stated and the comparison is designed to be fair. The report supports the methods section of a manuscript and gives readers confidence in the numerics.

An illustrative scenario

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

Imagine a doctoral researcher who has written a finite-volume code for a convection-diffusion problem. The code produces smooth profiles, but the observed convergence order from a manufactured-solution test is lower than the scheme's nominal order. Investigating, the researcher finds an error in the treatment of a boundary flux and an unintended first-order limiter in smooth regions. After correction, the observed order matches the theory, and the thesis can cite the verification test as evidence.

Questions to settle before you begin

• Which properties of the solution, such as shocks or boundary layers, must the scheme preserve?
• What order of accuracy do I expect, and how will I measure it?
• What limits the time step?
• How will I know solvers have converged?
• How will I compare my method fairly with existing ones?

Key terms

Consistency

The discrete equations approach the continuous ones as the mesh is refined.

Stability

Errors do not grow unboundedly during computation.

Courant number

A dimensionless ratio relating wave speed, time step and cell size.

Stiffness

A property of equations containing widely separated time scales.

Manufactured solution

A prescribed function used to test a code by constructing a matching source term.

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.

• Computational Engineering

  Application of numerical and computational methods to engineering problems where closed-form solutions are not available, with emphasis on model formulation, verification and validation.

• 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.

• 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.

• CFD Simulation Services

  Computational fluid dynamics studies of internal and external flows, thermal effects and mixing, built on an explicit statement of physics, boundary conditions, turbulence treatment and validation basis.

• Finite Element Analysis (FEA)

  Finite element modelling of structures and components for stress, deformation, thermal and dynamic behaviour, with attention to meshing, element choice, boundary conditions and verification against hand calculations or tests.