Hi there! My name is Adrian Kummerländer and I am a software developer currently studying mathematics in Karlsruhe. On these pages you will find blog articles covering amongst other topics some of my experiences in software development, open source and related tinkerings as well as repositories and information on some of my personal projects. If you have any comments or questions feel free to reach out. I hope you will find something here worth your time.

» Expressive meta templates for flexible handling of compile-time constants

May 25, 2019 | Adrian Kummerländer

So we recently released a new version of OpenLB which includes a major refactoring of the central datastructure used to handle various kinds of compile-time constants required by the simulation. This article will summarize the motivation and design of this new concept as well as highlight a couple of tricks and pitfalls in the context of template metaprogramming.

» Fun with compute shaders and fluid dynamics

December 22, 2018 | Adrian Kummerländer

As I previously alluded to, computational fluid dynamics is a current subject of interest of mine both academically1 and recreationally2. Where on the academic side the focus obviously lies on theoretical strictness and simulations are only useful as far as their error can be judged and bounded, I very much like to take a more hand wavy approach during my freetime and just fool around. This works together nicely with my interest in GPU based computation which is to be the topic of this article.

» On NixOS, GPU programming and other assorted topics

June 23, 2018 | Adrian Kummerländer

So I recently acquired a reasonably priced second-hand CAD workstation computer featuring a Xeon CPU, plenty of RAM as well as a nice Nvidia K2200 GPU with 4 GiB of memory and 640 cores as the heart of the matter. The plan was that this would enable me to realize my long hedged plans of diving into GPU programming - specifically using compute shaders to implement mathematical simulation type stuff. True to my previously described inclination to procrastinate interesting projects by delving into other interesting topics my first step to realizing this plan was of course acquainting myself with a new Linux distribution: NixOS.

» Symbolically generate D3Q19 OpenCL kernel using SymPy

June 15, 2019 at 20:45 | symlbm_playground | d71fae | Adrian Kummerländer

My recent experiments in using the SymPy CAS library for automatically deriving optimized LBM codes have now evolved to the point where a single generator produces both D2Q9 and D3Q19 OpenCL kernels.

Automatically deriving kernel implementations from the symbolic formulation of e.g. the BGK relaxation operator presents itself as a very powerful concept. This could potentially be developed to the point where a LBM specific code generator could produce highly optimized GPU programs tailored to arbitrary simulation problems.

» Experimental visualization of the velocity curl

April 28, 2019 at 12:53 | compustream | ecaf66 | Adrian Kummerländer

Calculating the curl of our simulated velocity field requires an additional compute shader step. Handling of buffer and shader switching depending on the display mode is implemented rudimentarily for now. Most of this commit is scaffolding, the actual computation is more or less trivial:

const float dxvy = (getFluidVelocity(x+1,y).y - getFluidVelocity(x-1,y).y)
                 / (2*convLength);
const float dyvx = (getFluidVelocity(x,y+1).x - getFluidVelocity(x,y-1).x)
                 / (2*convLength);

setFluidExtra(x, y, dxvy - dyvx);

This implements the following discretization of the 2d curl operator:

Let V:N2R2V : \mathbb{N}^2 \to \mathbb{R}^2 be the simulated velocity field at discrete lattice points spaced by ΔxR>0\Delta x \in \mathbb{R}_{\gt 0}. We want to approximate the zz-component of the curl for visualization:

ω:=xVyyVx\omega := \partial_x V_y - \partial_y V_x

As we do not possess the actual function VV but only its values at a set of discrete points we approximate the two partial derivatives using a second order central difference scheme:

ω(i,j):=Vy(i+1,j)Vy(i1,j)2ΔxVx(i,j+1)Vx(i,j1)2Δx\overline{\omega}(i,j) := \frac{V_y(i+1,j) - V_y(i-1,j)}{2 \Delta x} - \frac{V_x(i,j+1) - V_x(i,j-1)}{2 \Delta x}

Note that the scene shader does some further rescaling of the curl to better fit the color palette. One issue that irks me is the emergence of some artefacts near boundaries as well as isolated “single-cell-vortices”. This might be caused by running the simulation too close to divergence but as I am currently mostly interested in building an interactive fluid playground it could be worth it to try running an additional smoothening shader pass to straighten things out.

» Add basic physical scaling and Knudsen quality criterion

April 16, 2019 at 22:45 | compustream | fc02e4 | Adrian Kummerländer

The paper Automatic grid refinement criterion for lattice Boltzmann method by Lagrava et al. describes a criterion for measuring the local simulation quality using a comparison of the theoretical Knudsen number and the quotient of the cells’s non-equilibrium and equilibrium function.

While this criterion was developed to enable automatic selection of areas to be refined, it also offers a interesting and unique perspective on the fluid structure.

As the criterion requires calculation of the modeled Reynolds-, Mach- and Knudsen-numbers I took the time to set up the basics for scaling the simulation to actually model a physical system. Or rather calculating which physical model is represented by the chosen resolution and relaxation time.

» Published my BSc thesis on grid refined LBM in OpenLB

March 26, 2019 at 20:23 | grid_refinement_bsc_thesis | e4ba16 | Adrian Kummerländer

In addition to the PDF (German, ~60 pages) all sources including any referenced simulation data are available on Github and cgit. The resulting actual implementation of the grid refinement method by Lagrava et al. in OpenLB is currently not available publicly and likely wont make it into the next release. Nevertheless – if you are interested in the code and I have not yet found the time to release a rebased patch for the latest OpenLB release don’t hesitate to contact me.

Visual comparison between refined and unrefined flow around a cylinder

As a side note: The gnuplot-based setup for efficiently transforming Paraview CSV exports into plots such as the one above (i.e. plots that are neither misaligned Paraview screenshots nor overlarge PDF-reader-crashing PGFPlots figures) might be of interest even if one doesn’t care about grid refinement or Lattice Boltzmann Methods (which would be sad but to each their own :-)).

» Compustream performance improvements and interactive wall drawing

February 25, 2019 at 22:08 | compustream | 846665 | Adrian Kummerländer

I found some time to further develop my GLSL compute shader based interactive LBM fluid simulation previously described in Fun with compute shaders and fluid dynamics. Not only is it now possible to interactively draw bounce back walls into the running simulation but performance was greatly improved by one tiny line:

glfwSwapInterval(0);

If this function is not called during GLFW window initialization the whole rendering loop is capped to 60 FPS – including compute shader dispatching. This embarrassing oversight on my part caused the simulation to run way slower than possible.

» Describe custom gitolite and cgit setup

October 1, 2018 at 08:26 | nixos_system | 55daf8 | Adrian Kummerländer

Replaces short-term Gitea instance on code.kummerlaender.eu.

The main reason for implementing this more complex setup is that Gitea both lacks in features in areas that I care about and provides distracting features in other areas that I do not use.

e.g. Gitea provides multi-user, discussion and organization support but doesn’t provide Atom feeds which are required for Overview.

This is why exposing gitolite-managed repositories via cgit is a better fit for my usecases.

Note that gitolite is further configured outside of Nix through its own admin repository.

As a side benefit pkgs.kummerlaender.eu now provides further archive formats of its Nix expressions which simplifies Nix channel usage.