How to choose simulation software

There is no shortage of “best simulation software” lists, and most are written by somebody with a horse in the race. We are a vendor, so a ranking from us would be worth exactly nothing to you — and you would be right to discount it.

What is genuinely transferable is the set of questions that decide whether a tool works for a particular team. They are mostly not about physics, which is the surprising part: the solvers in serious contention are all capable. Projects fail on licensing, on meshing, on nobody having time to learn it, and on results nobody else can check.

Write down the actual engineering question and what you would do differently depending on the answer. “Will this enclosure keep the electronics under 85 °C at 40 °C ambient” is a specification. “We should do some thermal CFD” is not.

That sentence tells you which analysis type you need, what accuracy would be sufficient, and — often — that a much cheaper analysis than the one you were imagining would settle it.

More simulation projects die here than on capability. Things to establish before anything else:

• What is the unit of purchase? Per named user, per concurrent seat, per core, per solve, or per hour of compute — these behave very differently as usage grows.
• What does it cost to run bigger? Some models charge by mesh size or parallel cores, so the second engineer or the finer mesh triggers another purchase.
• Is it annual commitment or monthly? If simulation is occasional, a twelve-month lock-in for four weeks of use is poor value regardless of the sticker price.
• Does the licence follow the person or the machine? This decides whether working from home or on a laptop is possible.
• What happens when you stop paying? Can you still open old cases and read old results, or does the archive become unreadable?

Check the analyses you need today, and then check the one you will need next. Thermal work has a habit of turning into coupled work; structural work acquires fatigue; CFD acquires a free surface.

Ask specifically whether the adjacent capability is in the same tool, a separate product with its own price, or not available. A stack that requires three tools and manual file transfer between them is a real ongoing cost, and it is usually invisible at evaluation time.

For most users, meshing consumes more time than everything else combined. It is also the part that demonstrates worst — a vendor demo uses geometry prepared in advance, and your CAD is not that geometry.

Test it on your own worst part: something with slivers, small features, and the kind of imported geometry your suppliers actually send. Ask how much manual clean-up it needed, whether boundary layers were inserted where they were asked for, and whether the mesh quality report is honest about what it produced.

Ask what the tool has been validated against, and ask to see it. A serious answer is a set of benchmark cases against published experimental data with the differences stated — not a gallery of colourful contour plots.

Then ask what the software gives you for validating your own case. Can you run a mesh independence study without repeating every setup step by hand? Does it show convergence honestly, including when it is poor? Does the output state the threshold behind a verdict, or just a pass badge? A tool that makes it easy to check your work is worth more than one that makes results look impressive — see verification and validation for why.

Establish whether the software runs on the machines you have, whether it needs Linux, and whether it can use the cores in your workstation without an additional licence.

For cloud-based tools, ask where the data goes and whether that is acceptable for your sector — for defence, medical or anything under NDA, the answer is often that geometry must not leave the building, and that decision alone eliminates a category of options.

The question nobody asks at evaluation and everybody asks at renewal. If you leave, do you keep anything? Cases in a proprietary binary format are worthless outside the tool that wrote them. Cases in an open solver’s native format remain runnable indefinitely, with or without a front end.

This is also why a tool built on open-source solvers is structurally different: your case files remain valid input to a solver that will exist whatever happens to the vendor.

• Use a case with a known answer. Something you have measured, or a published benchmark. Evaluating on a case whose answer you do not know teaches you nothing about accuracy.
• Let your engineer drive, not the vendor. A specialist can make anything look easy. What matters is how long it takes the person who will actually use it.
• Time the whole path. From CAD file to a report somebody else could act on — including the meshing and the writing-up, not just the solve.
• Break it deliberately. Give it a bad mesh, a silly boundary condition, a diverging case. How a tool behaves when things go wrong is most of what you will experience in the first six months.

It would be inconsistent to spend a page arguing against vendor rankings and then finish with one, so plainly: SHD Sim is a desktop application built on OpenFOAM, priced per seat per month or year, with a free tier that runs real cases up to 250,000 cells of fluids, or 100,000 nodes of solid and no account required to download.

It is not the most capable or the most validated CFD product available, and there are cases — deep customisation, physics we do not cover, established Linux workflows — where it is the wrong answer and plain OpenFOAM or a larger commercial tool is the right one.