Selection of programming languages for the design of turbomachines

Table of Contents

1. General requirements

  • Very fast. However, computations are not expected to exceed in complexity or memory requirements.
  • Small footprint.
  • Parallelizable, either in code or through external tools. Example: GNU Parallel or optimizers/scripts such as Dakota and OpenTURNS.
  • Easy to write and maintain (that is probably more a programmer's task).
  • Welcoming: the code should be clean, readable and understandable. It will be mostly worked by engineers. However, it should not be "designed" for them.
  • Documentation is a priority.

2. Language comparison

Some entries are purely subjective and based on feeling rather than actual experience and/or work.

Language Performace Runtime Portability Ease of development TOML Several implementations Being called by "C" Calling "C" (C++) Future Documentation Testing Performance measurement (appart from generic tools1) Library ecosystem Parallelization Scriptability Communication API Issues Pros GUI
C 11 Great None Great DIY Yes TOMLC99 GCC, Clang, Tcc, comercial Automatic Automatic (Manual interface) Stable for ever Doxygen External frameworks External frameworks, compiler Very large, slow growth Pthreads, OMP(I), libraries Lua, Scheme, TCL Yes, library Manual everything. No longer improving Very flexible. Tons of libraries. Slow development (manual, debugging) Gtk, Tk, Nuklear, IUP, SDL2?
C++ 20 Great None/Minimal Great Pretty good, manual dependencies Yes TOML11 or TOML++ <- GCC, Clang, comercial "extern C" or interface/wrapper Automatic Bright but with legacy Doxygen External frameworks External frameworks, <chrono>, compiler Very large std::threads, OMP(I), libraries Lua, Scheme, TCL Yes, library Very complex and large Modern and very high level. Tons of libraries. Nice development Qt/QML, ImGui, Gtkmm, Tk, FLTK
Rust > 2018 Great None Good Very good2 Yes TOML-rs or Taplo Rustc, GCC? Wrapper, Cbindgen Interface (C interface) Very bright Built-in (Rustdoc) Built-in Built-in (cargo bench) Medium, growing, mixed quality Semi-standard libraries Lua. Probably not needed Yes, semi-standard libraries Rapidly evolving -> breakages Very modern and memory safe. Rapid development Gtk, FLTK, ImGui
Fortran 08/18 Great None Great3 Acceptable, fpm for dependencies? Yes TOML-Fortran GFortran, Flang, LFortran, comercial Interface/wrapper, C API, -fc-prototypes Interface (Shroud, C interface) Rather stable FORD (Python3), Doxygen (limited) naturalFRUIT, Zofu, Vegetables External frameworks, compiler Large, old, very slow growth CAF, OMP, OMPI TCL?… Lua-5.3, Lua-5.4 Maybe, JSON, XML Tailored for HPC Easy to write performing code. Simple. Average development Gtk-Fortran, Tk…
Ada 2X Great None/Minimal Great3 Good Yes Ada-TOML GCC, GNAT CE4, commercial Interface/wrapper, -gnatceg Interface, -fdump-ada-spec (C interface) Rather stable GNATdoc AUnit, Ahven - Small, high quality, slow growth Spawn, Tasks, parallel5 Tashy2, Tahsy, old, Ada-Lua Maybe, JSON, XML Lack of scientific libraries. Niche. A lot of GPLv36 Forces high quality code. May become provable. Clear and concise. Average development Gtk-Ada, Tk
Julia 1.X Great JIT Only mayor OS and Archs Very good7 Yes TOML.jl Julia… C API Automatic/Interface (Cxx.jl) Very bright Built-in Built-in Built-in Medium, growing Built-in Not needed Yes Rapidly evolving -> breakages, warmup JIT Fresh, fast and flexible. Rapid development (Basic) QML, Tk, Web (ugh)
Python 3.X "Bad"8 VM/JIT Great Very good7 Yes TOML or Tomlkit CPython, PyPy, Nuitka, "Numba" C API Ctypes (Boost.Python (ugh)) Bright Built-in Built-in Built-in Extremely large Semi-built-in Not needed Yes May break again TM. Slow. Lack of parallelization. Mess to manage versions/distributions Used by everybody in science/engineering. Simple and flexible. Rapid development (debugging…) Qt (PySide2), Tk (Tkinter)
Common Lisp?                                      


  • Is it really that important that the language is portable? The application is going to be a desktop one, which means it will mostly run on Windows, Mac, Linux and maybe FreeBSD. In terms of architecture, that means only x8664 and arm64 are relevant.
  • Is it really that important that the language has several implementations? As long as there is commitment from the developers to keep improving/maintaining them and keep them libre, that is about it.
  • The necessity of an scripting language is still to be assessed. Most likely some Posix Shell and some standard utilities is all that is needed.
  • The same can be said for the GUI. I do not think that it will be needed.
  • Package management for Rust, Python, Julia, Ada and Fortran can be done through a package manager. That may be useful for development. But deployment should be done in an standard manner (simple make).
  1. Fortran

    FORD and Fypp (Fortran stdlib) require Python 3. Fpm as far as I know still requires Haskell.

3. Libraries and programs to be used

3.1. Fluid properties

  • CoolProp: real fluid properties. Also computes mixtures. Written in C++, has interfaces for several languages, mostly Python and Modelica. License: MIT.
  • Thermopack: real fluid properties, has several EoS models. Written in Fortran with a Python GUI. License: MIT.
  • Cantera: combustion and reactions library. Written in C++, has interfaces for Python and Fortran. License: BSD-3.
  • Peng-Robinson Cubic Equation: take a look at PREOS (Python), PengRobinsonEOS (C++), PyThermophy (Python, implements several other methods), CEOS (Fortran, several cubic methods), FreeFluidsC (C, several EOS models).
  • HelmholtzMedia: Modelica library.

3.2. Optimizers, UQ and data analysis

3.3. Paralellization

3.4. Geometry generation

  • T-Blade3: blade generation. Looks really, really good. Written in Fortran. License: GPLv2-or-later.
  • Xfoil: very interesting. Written in Fortran. License GPLv2.
  • GMSH: from the webpage: A three-dimensional finite element mesh generator with built-in pre- and post-processing facilities. Very well known and powerful. Written in C++, with interfaces for Python, Julia, C++ and C. License: LGPLv2-or-later.
  • OpenCSM: ??? Take a look. License: LGPLv2.1.
  • Turbo: blade geometry generation. Take a look. Written in C++ and uses GMSH.
  • CadQuery: library to create parametric geometry. Written in Python, based on OCCT. License: Apache 2.0.
  • OpenSCAD: parametric 3D modelling program. Written in C++. License: GPLv2.
  • VTK: data manipulation and visualization toolkit. License: BSD-3.

3.5. Simulators

  • QBlade: take a look, lets see how they do it.
  • CACTUS: take a look, lets see how they do it.
  • OpenProp: take a look, lets see how they do it.

3.6. Others

  • Fluids: from Github: Fluids is open-source software for engineers and technicians working in the fields of chemical, mechanical, or civil engineering. It includes modules for piping, fittings, pumps, tanks, compressible flow, open-channel flow, atmospheric properties, solar properties, particle size distributions, two phase flow, friction factors, control valves, orifice plates and other flow meters, ejectors, relief valves, and more. Written in Python.

4. Other considerations



gprof, valgrind (cachegrind), oprofile, gperftools.


The compiler helps a lot with the memory. And the language is very nice.


In principle.


GNAT CE is a prepackaged version (and some extra goodies) of FSF GCC that is distributed under the GPLv3.


Ada 202X supports the parallel keyword which is supposed to aid in the parallization of code. However, as of GNAT 2021, GCC 11, it is not implemented.


A lot of libraries that are available, are only available as GPLv3 code. This is not necessarily a bad thing, but it needs to be taken into account.


The language comes with a very expresive syntax and with "batteries included".


Performance by default is quite bad. Making it performant requires the use of optimized libraries and/or implementations. This is expected.

Author: Fernando Oleo Blanco

Created: 2021-05-28 Fr 21:16