I started writing my first CFD code in 2007. Back then, it seemed obvious to me that CFD codes should be general purpose, and written for skilled CFD practitioners. “If you can’t write down your wall functions,” I thought, “you really shouldn’t be using a CFD code.”

Things changed. Around 2009 I became interested in whether CFD codes designed with a single purpose could outperform general purpose CFD codes. I was also interested in whether CFD could be interactive – whether the user could alter the geometry on the fly, and not be confined to the typical Pre-Solve-Post routine of commercial codes. VIV-Sim was my baby.

CFD had evolved in my mind. I no longer viewed it as a technology that should be closely guarded by the CFD intelligentsia, but instead as an analysis tool that any engineer could use. Combining an engineer’s specialist knowledge with a high-quality CFD code that had virtually no barrier to entry was the new way forward.

The more this idea gained momentum, the more it became apparent that it was the design of CFD software that was holding CFD back from widespread use. When software asks its users to choose between the Eddy-Dissipation Model and Eddy-Dissipation Concept combustion model, it isn’t a consequence-free choice – it is a choice that excludes everyone who doesn’t know the difference between the two.

As we develop in:Flux at Insight Numerics, we constantly ask ourselves, “Who is going to use the software?” Our goal is to automate CFD at the highest quality so that it can be put in the hands of those who need it. A Process Safety Engineer should be able to run high-quality CFD simulations of dispersion and fire simulations without any knowledge of CFD…without having to write down their wall functions.