History & Community

The road to GeLB

note

If you are in a hurry, it is OK to skip this section. However, you may want to revisit it later, to understand some of the design decisions at the core of GeLB.

GeLB started out as the obsession of a single person (Dragoș-Bogdan Chirilă), a physicist who got drawn into the world of high-performance computing in general (with a focus on LBM algorithms). The road to the initial versions of GeLB was long and non-obvious, with several false starts (which were, nonetheless, very instructive):

• Dragoș started his LB adventure as a student (around 2007), when he had the fortune to contribute to a larger (in-house) code-base, which exposed him to many aspects related to writing scientific software (general workflow, checking correctness, and improving computational performance). To better understand the various concepts related to LB in isolation, he started writing many small examples (mostly using Fortran), to simulate benchmark problems.

• Soon, it became obvious that most of the examples had many things in common, and some of this functionality (mainly related to simulation input / output (I/O)) was aggregated into reusable functions. Unfortunately, some of the performance-critical aspects (such as the memory layout of the lattice) proved more difficult to refactor. Fortran is not known for its generic programming capabilities, so the Dragoș initially wrote some M4 macros to modify the source-code.

• Of course, the M4 approach later proved to be unsustainable. This motivated a first re-write -- all the code was moved to C++, which had better support for object-oriented programming (OOP) and also for generic programming, via templates.

• For a while, the C++ version seemed to be reasonable. However, the complexity of the template-code (which became proper template metaprogramming), grew constantly. By the time it became obvious that LB was a natural fit for the emerging general-purpose graphics processing units (GPGPUs), any error in the template code would produce many pages of cryptic error-messages at compile-time. It turned out that, while C++ templates are great for simpler scenarios, they were never meant to be used as a vehicle for creating software which works well across a wide spectrum of hardware architectures. Dragoș was simply unable to port the code to GPGPUs.

• While brainstorming for better alternatives, three important conclusions crystalized:

  1. Without explicitly aiming for this, the code evolved towards the functionality normally provided by a compiler. If he were to continue with this, he might as well write an actual compiler.

  2. If the goal is to specify the simulation we want to build from a more abstract point of view, many of the features of general-purpose programming languages (such as C++ or Fortran) are actually getting in a way. Instead, it would be better to design a domain-specific language which defines some abstractions for code-patterns commonly used by the LB community. For example, all of the existing implementations need a central data-structure (named lattice in GeLB), on which we need to:

     • write some initial data (functionality provided via initializers in GeLB)
     • read distribution-functions (DFs) from the lattice state at the current time-step, to eventually calculate the DFs at the next time-step (functionality provided via dynamics in GeLB), and
     • evaluate some macroscopic quantities (density, velocity, etc.), based on the lattice state (functionality provided via gauges in GeLB).

  3. In a DSL, it is reasonable to impose some restrictions, if these can improve the ability of the compiler to generate good code, without making it too hard for users of the language to express the algorithm they have in mind. This is why there are no looping constructs (for, while, do, etc.) in GeLB -- these are notoriously difficult to auto-parallelize, and the functionality we actually need in LB where people use looping constructs is better supported by a few intrinsic functions.

  4. On the implementation side, the work of an aspiring compiler-writer is much easier nowadays, with the advent of libraries such as ANTLR4 and by "piggybacking" on the facilities / packages available in a higher-level language (Python in the case of GeLB).

• Thus, another journey began, where most of the functionality provided by the earlier simulations of the author was gradually assimilated into a new project (named GeLB, which is an acronym standing for "Generic

  Lattice Boltzmann"). This was the longest part of the journey, but also the most rewarding.

• The journey now continues with the release of the code to the community, and (perhaps) by welcoming people like you to contribute (TODO make document listing possible ways to contribute, and point to that document from here).

Who are we?

Although GeLB is still in the early stages (compared to established languages), it is growing fast. Dragoș is still heavily involved, but fortunately this is no longer a single-man project. We are a group of researchers from around the world, who are passionate about LB and what it can offer. Join us, so that we can accelerate the rate of innovation of this field (and the extent of its outreach to the rest of the world).