The honest framing

Commercial CFD packages are extraordinary. They fail on custom geometry not because the numerics are weak, but because the workflow around them assumes conventional shapes, and because their physics and licensing are fixed. Know which of those three is actually blocking you before spending anything.

"Off-the-shelf CFD does not work for us" is a conclusion teams usually reach after months of frustration. It is often correct, but for reasons different from the ones they state. Diagnosing it properly decides whether you need better CAD hygiene, a different licence, or genuinely your own solver.

Where the workflow actually breaks

1. Meshing, not solving

By a wide margin the most common failure. Automatic meshers assume geometry that is watertight, reasonably proportioned, and free of unnecessary detail. Real engineering CAD is none of those things — it contains fastener threads, tiny fillets, sliver faces from imports, and gaps below tolerance.

The symptom is a mesh that either will not generate, or generates with cells so skewed the solution never converges. Engineers then spend days manually repairing geometry per variant, and the analysis stops being repeatable — which is the real loss.

2. Thin gaps and high aspect ratios

Narrow channels, seals, blade tip clearances, and coating layers force enormous cell counts to resolve properly, or produce cells so stretched that accuracy collapses. Geometry that is entirely reasonable physically can be badly behaved numerically.

3. Physics outside the supported set

If your problem involves non-Newtonian rheology, unusual phase change, bespoke reaction kinetics, or a coupling the package does not implement, you can sometimes reach for user-defined functions — and sometimes discover the hooks you need are not exposed. That ceiling is hard.

4. Licensing arithmetic

Per-core licensing means the simulation you need may be blocked by cost rather than capability. Teams routinely have hardware sitting idle because adding cores costs more in licences than in compute.

Diagnose before you conclude. If your pain is meshing, a custom solver will not help — you will simply own the meshing problem too. Custom solvers help when the physics or the licensing model is the constraint, or when a narrow repeated analysis can be made dramatically faster by specialising.

A decision test

Your symptomMost likely causeCheapest fix to try first
Mesher fails or produces bad cellsDirty or over-detailed CADDefeature and heal the geometry
Solution will not convergeMesh quality or boundary setupMesh study; revisit BCs
Results disagree with experimentModel choice, not the toolTurbulence model / wall treatment review
Cannot run at required resolutionLicence core limitsRenegotiate, or evaluate owning the solver
Required physics unsupportedGenuine package ceilingUDF if exposed; otherwise custom
Cannot ship simulation in your productLicence termsCustom or permissively-licensed base

Three of those six are fixed upstream of the solver. Spending on a custom code to solve a CAD hygiene problem is an expensive way to inherit the same problem.

What a specialised solver actually buys you

When the analysis is narrow and repeated, specialising is where custom genuinely wins:

  • A mesh generator that understands your geometry family. If every part you analyse is a variant of the same topology, a purpose-built mesher removes the fragile step entirely.
  • Physics implemented exactly once, correctly. No fighting a general framework to express your model.
  • Speed from specialisation. A solver that exploits your problem's structure can be far faster than a general one solving the same case.
  • Embeddable and licence-free at runtime. You can ship it inside your own product.
  • Automation without seat limits. Design-of-experiments and optimisation loops stop being licence-constrained.

What you take on

It would be dishonest to present only the upside. Owning a solver means owning:

  • Verification and validation, permanently — every physics change needs fresh evidence.
  • Meshing, or an integration with something that meshes.
  • Pre- and post-processing workflow your engineers will actually use.
  • Maintenance at roughly 15–20% of build cost per year.
  • Knowledge retention, so the solver is not hostage to one engineer.

A staged path that de-risks the decision

  1. Clean the geometry pipeline first. Defeaturing and healing solves a surprising share of "the tool does not work" complaints.
  2. Prototype the physics in a framework. A custom OpenFOAM solver proves the model at a fraction of from-scratch cost.
  3. Benchmark honestly against your tuned commercial workflow — accuracy and wall-clock, on your cases.
  4. Only then commit to a bespoke kernel, with validation cases defined before development begins.

Not sure which of the three constraints is actually blocking you? Describe your geometry and physics — we will tell you honestly if the answer is better CAD prep or a different licence rather than a custom build. See our CFD solver service.

Frequently asked questions

The solver rarely fails outright — meshing and setup do. Thin gaps, high aspect ratios, and dirty CAD produce meshes that will not converge or that need so much manual repair the workflow stops being repeatable. That is a workflow failure even when the solver is technically fine.
Usually yes, and it is much cheaper. A large share of meshing pain traces to geometry with gaps, slivers and unnecessary detail. Defeaturing and healing the CAD is the first thing to try before concluding the tool is wrong.
When the same class of analysis runs repeatedly on geometry the commercial workflow handles badly, when you need physics the package does not implement, or when licensing or embedding constraints rule the package out entirely.