Why GeLB (detailed)

There are probably thousands of interesting things you could start learning today (if you only had the time and energy!). So, it is very healthy to be skeptical when someone on the internet tries to convince you to invest your precious time into a particular technology. TODO GeLB is exciting, and can save time (right now if they are beginners, or at later stages if they are more advanced w.r.t. LB)

Opinions ahead...

Many of the point listed below are opinionated -- often there is no rigorous data, so we have only our experience to draw upon. If your experience is different, please contact us, so that we make this document as objective as possible.

TODO explain that the solutions/features offered by GeLB are shown as tips in green.

TODO explain reasons to try GeLB, e.g.:

• what GeLB has to offer,
• what is wrong with the other approaches (in-house development of simulation code or aggregation around LB-focused libraries)

TODO

• ability to test and use (as conveniently as possible) the latest algorithm appearing in the LB literature
• ability to easily share our contributions with the larger community.

TODO Explain what's wrong with the prevailing approaches:

• in-house development of simulation code:

  • in the case of research groups, the incoming students often don't have extensive programming experience, and the initial design can be "lost" as features are added hastily
  • ...

• aggregation around a few LB-focused libraries:

  Software libraries / packages are the foundation of modern computing. However, there are some things that a library cannot do (things for which we need the power of a compiler)

Here is a more detailed discussion of the points:

1. Easy to debug: In our opinion, the simplicity of the core computational kernel in LB simulations can be misleading, because it suggests that the programming effort is trivial.

   Granted, it is perfectly feasible to simulate a simple benchmark problem (such as Poiseuille flow) by writing only a "screenful" of code (especially in higher-level languages such as Python and Matlab). This is a very educational (and, dare we say, inspiring?) experience for newcomers, which we strongly recommend.

   However, the programming effort can grow fast when we want to move past these initial stages. Suddenly, things are no longer trivial when we want (for example) to:

   • improve the accuracy of our simulations, by implementing more complex boundary conditions (BCs),
   • parallelize / optimize our simulation, to make the computing time (or memory requirements) more bearable, or to
   • support more general / non-hard-coded geometries, without sacrificing accuracy (i.e. when bounce-back BCs are not enough).

   tip

   GeLB makes debugging much easier, by enforcing a lot of sanity checks at compile-time. For example, the GeLB compiler (gelbc) can detect common issues such as:

   • When we try to reduce the memory footprint (by avoiding the two-lattice pattern), we can easily introduce bugs where an update at one node may incorrectly overwrite old DFs which are still needed for updating another node. This kind of "old-state lattice corruption" problem is very hard to debug without GeLB.
   • access of distribution functions (DFs) which were not initialized,
   • attempts to read from / write to non-existent DFs (DFs beyond the bounds of the lattice, perhaps due to incorrect implementation of BCs),
   • TODO...mention more GeLB features (mostly the safety checks @MidWare fit here)

2. Taking advantage of the available hardware: We are all in different parts of the world, with different types of hardware available to us -- maybe just a low-end laptop, maybe a powerful workstation with GPUs, or maybe even a powerful TOP500 cluster. We want the ability to use whatever is available to us. Also, it would be nice if we could test our idea (in a low-resolution version) on a small machine, and easily switch to a large machine for "production" runs -- this way, we can iterate fast, without having to wait in a queue for cluster resources. While these requirements sound simple in theory, in practice they are difficult to satisfy, due to the sheer variety of the hardware. Instead, what often happens is that the code is tuned to run on a particular machine, making it impractical to switch to another machine for a quick test.

   tip

   TODO classes of hardware identified by GeLB devs (we can define a few common situations)

   When they hear the words "high-level code", some people (especially the more experienced programmers) immediately think of low performance. However, performance is has been a concern of the GeLB community from the very beginning, being the second priority (after correctness).

   tip

   When it comes to performance, a central hypothesis when we designed GeLB is that, by imposing some well-thought-of restrictions on the language (which do not significantly hinder the ability to express your simulation problem, but which exclude some low-level optimizations from the simulation code), the compiler has a much better chance of producing high-quality code, which runs well (if not optimal) on the available hardware. For example, there are no pointers in the GeLB language.

   That said, if you are one of those people who actually enjoys working on the low-level / performance-critical issues, there is a place for you in the GeLB community! Although GeLB may not (yet) be as fast as your beautifully hand-tuned code, you can get involved by integrating some of your know-how to the GeLB compiler. Your contributions will then help your future self (and the entire GeLB community). If you are interested, the TODO:link-to-dev-guide was created specially for you.

3. Support for high-performance I/O: TODO

4. Support for pausing and resuming simulations: TODO when the underlying machine needs to be restarted, or when we want to switch to another machine

5. Support for estimating {memory, compute-time, storage} required for simulations: TODO

6. Support for other features: TODO features which make life / work easier...