Selection of programming languages for the design of turbomachines
Sitemap — — — Webring — — — Repositories — — — About
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.
| 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) |
| 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.
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
- OpenFOAM: CFD, FSI. See https://github.com/arattner1/superThermo
- SU2: CFD.
- FEniCS: Generic.
- Deal.II: Generic.
- MOOSE: Generic.
- GetDP/ONELAB: Generic.
- MBDyn: solid multibody dynamics.
- MIT webpage: http://acdl-web.mit.edu/software
—
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
- For plotting, PLplots supports C, C++, Fortran, Ada, Python, Lua, Lisp. For language agnostic plotting, there is gnuplot. Julia and Python come with tons of plotting/graphing utilities.
- We may not need a direct "interop" with scripting languages. Maybe we could use something like sockets or an API. However, this could easily become messy.
- I need to see how OpenTURNS (C++ and Python) and Dakota deal with external programs. However, by an initial assesment, it seems that they provide a clear way of calling external programs with their generated inputs. This most likely requires some fiddling/conversion into a valid TOML input.
- Very very very interesting: https://d1qmdf3vop2l07.cloudfront.net/sage-newt.cloudvent.net/compressed/_min_/f254b93a1448a13f7f4007b9ea3e060d.pdf
- Same as above: https://hal.inria.fr/hal-02389654/document
- Same: https://repository.tudelft.nl/islandora/object/uuid%3A9bbcf030-af4b-42c8-a7e5-2157bde13706
- Maybe interesting: https://www.researchgate.net/publication/236335867_Blade_Geometry_Optimization_for_Axial_Flow_Compressor
- Very interesting: https://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=7230&context=etd
- Same: https://www.netl.doe.gov/sites/default/files/gas-turbine-handbook/2-0.pdf
- Maybe interesting: http://www.medwelljournals.com/abstract/?doi=jeasci.2016.2769.2774
- Same as above: https://www.ijedr.org/papers/IJEDR1301005.pdf
- Same: https://www.hindawi.com/journals/ijrm/2018/6398501/
- Interesting: https://asmedigitalcollection.asme.org/turbomachinery/article-abstract/139/5/051008/378824/A-Database-of-Optimal-Airfoils-for-Axial?redirectedFrom=fulltext
- Same: https://forum.freecadweb.org/viewtopic.php?t=22295
- Same: https://github.com/msaisiddhartha/CIMdes
- Very interesting: https://github.com/nikander/VINK
- VERY, VERY, VERY interesting: https://online.tugraz.at/tug_online/voe_main2.getVollText?pDocumentNr=270196&pCurrPk=66975
- Take a look: https://software.nasa.gov/propulsion
- ": https://www.sciencedirect.com/topics/engineering/fluid-property
- ": https://opencourses.emu.edu.tr/pluginfile.php/4498/mod_resource/content/1/Chapter2.pdf
- ": http://web.nchu.edu.tw/pweb/users/cmchang/lesson/10174.pdf
- ": http://depa.fquim.unam.mx/amyd/archivero/TEORIADEECUACIONESDEESTADO_3411.pdf
- ": https://github.com/ldenies/tabulatedProperties
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
GNAT CE is a prepackaged version (and some extra goodies) of FSF GCC that is distributed under the GPLv3.
5
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.
6
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.
7
The language comes with a very expresive syntax and with "batteries included".
8
Performance by default is quite bad. Making it performant requires the use of optimized libraries and/or implementations. This is expected.