Selection of programming languages for the design of turbomachines

Before anything else

This is an old blog post that I never intended for it to become public. However, it has some interesting information and if I recall correctly, it was the first article I started writing, so it has some sentimental weight to it.

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.

Language comparison

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

LanguagePerformaceRuntimePortabilityEase of developmentTOMLSeveral implementationsBeing called by “C”Calling “C” (C++)FutureDocumentationTestingPerformance measurement (appart from generic tools1)Library ecosystemParallelizationScriptabilityCommunication APIIssuesProsGUI
C 11GreatNoneGreatDIYYes TOMLC99GCC, Clang, Tcc, comercialAutomaticAutomatic (Manual interface)Stable for everDoxygenExternal frameworksExternal frameworks, compilerVery large, slow growthPthreads, OMP(I), librariesLua, Scheme, TCLYes, libraryManual everything. No longer improvingVery flexible. Tons of libraries. Slow development (manual, debugging)Gtk, Tk, Nuklear, IUP, SDL2?
C++ 20GreatNone/MinimalGreatPretty good, manual dependenciesYes TOML11 or TOML++ <-GCC, Clang, comercial”extern C” or interface/wrapperAutomaticBright but with legacyDoxygenExternal frameworksExternal frameworks, <chrono>, compilerVery largestd::threads, OMP(I), librariesLua, Scheme, TCLYes, libraryVery complex and largeModern and very high level. Tons of libraries. Nice developmentQt/QML, ImGui, Gtkmm, Tk, FLTK
Rust > 2018GreatNoneGoodVery good2Yes TOML-rs or TaploRustc, GCC?Wrapper, CbindgenInterface (C interface)Very brightBuilt-in (Rustdoc)Built-inBuilt-in (cargo bench)Medium, growing, mixed qualitySemi-standard librariesLua. Probably not neededYes, semi-standard librariesRapidly evolving -> breakagesVery modern and memory safe. Rapid developmentGtk, FLTK, ImGui
Fortran 08/18GreatNoneGreat3Acceptable, fpm for dependencies?Yes TOML-FortranGFortran, Flang, LFortran, comercialInterface/wrapper, C API, -fc-prototypesInterface (Shroud, C interface)Rather stableFORD (Python3), Doxygen (limited)naturalFRUIT, Zofu, VegetablesExternal frameworks, compilerLarge, old, very slow growthCAF, OMP, OMPITCL?… Lua-5.3, Lua-5.4Maybe, JSON, XMLTailored for HPCEasy to write performing code. Simple. Average developmentGtk-Fortran, Tk…
Ada 2XGreatNone/MinimalGreat4GoodYes Ada-TOMLGCC, GNAT CE5, commercialInterface/wrapper, -gnatcegInterface, -fdump-ada-spec (C interface)Rather stableGNATdocAUnit, Ahven-Small, high quality, slow growthSpawn, Tasks, parallel6Tashy2, Tahsy, old, Ada-LuaMaybe, JSON, XMLLack of scientific libraries. Niche. A lot of GPLv37Forces high quality code. May become provable. Clear and concise. Average developmentGtk-Ada, Tk
Julia 1.XGreatJITOnly mayor OS and ArchsVery good8Yes TOML.jlJulia…C APIAutomatic/Interface (Cxx.jl)Very brightBuilt-inBuilt-inBuilt-inMedium, growingBuilt-inNot neededYesRapidly evolving -> breakages, warmup JITFresh, fast and flexible. Rapid development(Basic) QML, Tk, Web (ugh)
Python 3.X”Bad”9VM/JITGreatVery good10Yes TOML or TomlkitCPython, PyPy, Nuitka, “Numba”C APICtypes (Boost.Python (ugh))BrightBuilt-inBuilt-inBuilt-inExtremely largeSemi-built-inNot neededYesMay break again TM. Slow. Lack of parallelization. Mess to manage versions/distributionsUsed by everybody in science/engineering. Simple and flexible. Rapid development (debugging…)Qt (PySide2), Tk (Tkinter)
LuaJIT?
Common Lisp?
Scheme?
Dart?

Comments

  • 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).

Fortran

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

Libraries and programs to be used

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.

Optimizers, UQ and data analysis

Paralellization

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.

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.

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.

Other considerations

Footnotes

  1. gprof, valgrind (cachegrind), oprofile, gperftools. ↩

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

  3. In principle. ↩

  4. In principle. ↩

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

  6. 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. ↩

  7. 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. ↩

  8. The language comes with a very expresive syntax and with “batteries included”. ↩

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

  10. The language comes with a very expresive syntax and with “batteries included”. ↩