Costing a custom CFD solver is unlike costing business software, because most of the risk sits in a phase people forget to budget: proving the thing is correct. Writing a solver that produces plausible-looking colourful output is not difficult. Writing one whose numbers you can defend is where the effort concentrates.
What drives the cost
Five factors dominate, roughly in order of impact:
- Physics scope Incompressible laminar flow is a fundamentally smaller problem than compressible, reacting, or multiphase flow. Each additional physics coupling multiplies both implementation and validation effort.
- Dimensionality and mesh type 2D structured is far simpler than 3D unstructured. Arbitrary polyhedral meshes are harder again.
- Parallelism A serial solver is a fraction of the cost of a distributed MPI solver with good scaling. GPU acceleration adds another layer.
- Verification and validation Routinely 25–40% of total effort. This is the part that makes results defensible, and the part clients most often try to cut.
- Tooling around the solver Mesh import, boundary condition setup, post-processing output, restart files, and a usable interface.
Realistic cost bands
| Scope | Typical effort | Indicative cost |
|---|---|---|
| 2D single-physics solver, serial, verified | 4–6 months | ₹18L – ₹40L |
| 3D unstructured, RANS turbulence, MPI parallel | 8–14 months | ₹45L – ₹1.2Cr |
| Multiphysics or reacting flow, validated | 12–24 months | ₹1Cr+ |
| Custom OpenFOAM solver / physics library | 2–5 months | ₹8L – ₹30L |
| GPU acceleration of an existing solver | 3–6 months | ₹15L – ₹45L |
These are engineering-effort bands, not quotes. The honest way to price a specific project is to define the governing equations, the mesh types, the target hardware, and the validation cases first — at which point the estimate narrows considerably.
The cheapest option is usually the one nobody asks about. Before commissioning a solver, ask whether a custom OpenFOAM solver or physics library meets the requirement. It frequently does, at roughly a quarter of the cost, because you inherit meshing, parallelisation and post-processing rather than building them.
Where the budget actually goes
For a representative 3D parallel RANS solver, effort distributes roughly like this:
| Work item | Share | What it covers |
|---|---|---|
| Discretisation & core solver | 25–30% | Numerical scheme, fluxes, pressure-velocity coupling |
| Verification & validation | 25–40% | Manufactured solutions, benchmarks, error reporting |
| Linear solvers & preconditioning | 10–15% | Convergence behaviour on real problems |
| Parallelisation | 10–20% | Domain decomposition, communication, scaling |
| Mesh & IO handling | 8–12% | Import, partitioning, output for post-processing |
| Physics models | 10–20% | Turbulence closures and any custom models |
If a proposal does not allocate a substantial share to verification and validation, it is not a proposal for a CFD solver. It is a proposal for a program that produces numbers.
The costs after delivery
- Maintenance — budget 15–20% of build cost annually: compiler and dependency updates, bug fixes, and support for new mesh or hardware targets.
- Extending physics — each new model is a fresh implementation plus fresh validation.
- HPC operations — cluster time, scheduler integration, and the engineering to keep scaling as core counts grow.
- Knowledge retention — a solver understood by one person is a serious business risk. Documentation and a second engineer are not optional overheads.
Be sceptical of any cost comparison that omits maintenance. Custom-versus-licence models frequently compare a one-time build price against years of licensing, which flatters the custom option. Include annual maintenance and the comparison becomes honest — and sometimes reverses.
When the investment is justified
- Per-core licensing is capping the simulation size you can actually run.
- You need physics the commercial package does not implement and cannot be extended to.
- You must embed simulation inside a product you ship, which commercial licences prohibit.
- Export control or data residency rules out the tools otherwise available to you.
- The same class of analysis runs repeatedly, so a specialised solver can be far faster than a general one.
How to reduce cost without regret
- Narrow the physics ruthlessly. Solve your actual problem, not a general one. This is the single largest lever.
- Start serial, parallelise later if the architecture anticipates it. Correctness first, scaling second.
- Extend a framework where licence terms permit — you inherit an enormous amount of solved infrastructure.
- Define validation cases up front. Deciding what "correct" means afterwards is how V&V budgets triple.
- Do not build a GUI early. Scripted input is sufficient for engineers and costs a fraction.
Want a costed scope for a specific solver, including an honest recommendation if a commercial package or an OpenFOAM extension would serve you better? Describe your governing equations and target hardware. See our CFD solver development service.