Analytic Solution to the Piecewise Linear Interface Construction Problem and Its Application in Curvature Calculation for Volume-of-Fluid Simulation Codes

Abstract

The plane–cube intersection problem has been discussed in the literature since 1984 and iterative solutions to it have been used as part of piecewise linear interface construction (PLIC) in computational fluid dynamics simulation codes ever since. In many cases, PLIC is the bottleneck of these simulations regarding computing time, so a faster analytic solution to the plane–cube intersection would greatly reduce the computing time for such simulations. We derive an analytic solution for all intersection cases and compare it to the previous solution from Scardovelli and Zaleski (Scardovelli, R.; Zaleski, S. Analytical relations connecting linear interfaces and volume fractions in rectangular grids. J. Comput. Phys. 2000, 164, 228–237), which we further improve to include edge cases and micro-optimize to reduce arithmetic operations and branching. We then extend our comparison regarding computing time and accuracy to include two different iterative solutions as well. We find that the best choice depends on the employed hardware platform: on the CPU, Newton–Raphson is fastest with compiler optimization enabled, while analytic solutions perform better than iterative solutions without. On the GPU, the fastest method is our optimized version of the analytic SZ solution. We finally provide details on one of the applications of PLIC—curvature calculation for the Volume-of-Fluid model used for free surface fluid simulations in combination with the lattice Boltzmann method.

1. Introduction

Piecewise linear interface construction (PLIC)—first occurring in the literature for 2D in 1982 [1] and for 3D in 1984 [2]—refers to the problem of calculating the offset along the given normal vector of a plane intersecting a unit cube for a given truncated volume. There are five possible intersection cases (cf. Figure 1), of which the numbers (1), (2) and (5) have been already solved in the original 1984 work by Youngs [2], but the cubic polynomial cases (3) and (4)—considered impossible to algebraically invert [3]—in the majority of the literature are approximated by a Newton–Raphson iterative solution. Nevertheless, there does exist an analytic solution by Scardovelli and Zaleski (SZ) [4] and a single documented implementation thereof in Fortran [5], which also includes an approximative version termed APPLIC.

Here, we formulate the PLIC problem from the ground up—first in the inverse direction—and derive an alternative analytic solution for all intersection cases by inverting the inverse formulation. We then compare our novel solution with (i) the original SZ solution, (ii) an improved and micro-optimized version of the SZ solution developed in the present work, (iii) an iterative solution using Newton–Raphson and (iv) an iterative solution using nested intervals. Depending on the available microarchitecture (GPU/CPU), compiler optimization may strongly favor multiplications and additions while not speeding up trigonometric functions, impacting which of the algorithms is fastest.

Among the applications for PLIC are Volume-of-Fluid simulation codes such as FluidX3D [6,7,8] and others [9,10,11,12,13,14,15,16,17,18,19], often in conjunction with GPU implementations [6,7,8,20,21,22,23,24,25,26] of the lattice Boltzmann method [27,28,29], used for simulating free surface fluid flows. In particular, these simulations work on a cubic lattice, with every lattice point having a fill level assigned to it, and PLIC is used in the process of surface reconstruction during curvature calculation for calculating physical surface tension effects [6,7,8,9]. PLIC-VoF has applications in many areas—for example, computational science [6,7,30,31,32], civil [33,34] and aerospace engineering [35] and computer graphics [36]. In the final section of this work, we provide a detailed overview of the state-of-the-art curvature calculation procedure using PLIC.

2. Plane–Cube Intersection

Inputs to the PLIC algorithm are the truncated volume $V_0\in [0,1]$ and the (normalized) normal vector of the plane $\overrightarrow{n}={(n_x,n_y,n_z)}^{\mathrm{T}}$, $|\overrightarrow{n}|=n_x^2+n_y^2+n_z^2=1$. The desired output is the plane offset from the origin (center of the unit cube) along the normal vector $d_0$

$$V_0,{(n_x,n_y,n_z)}^{\mathrm{T}}\to d_0$$

(1)

where $d_0\in [-\frac{|n_x|+|n_y|+|n_z|}{2},\frac{|n_x|+|n_y|+|n_z|}{2}]$. The interval is determined by the normal vector orientation: depending on the normal vector, the maximum possible distance from the cube center to be still at least touching the cube in one point varies between $\frac{1}{2}$ (normal vector parallel to one of the coordinate system axes) and $\frac{\sqrt{3}}{2}$ (normal vector along the space diagonal).

2.1. Applying Symmetry Conditions to Reduce Problem Complexity

To reduce the amount of possible cases and to avoid having to consider all possible intersections of the plane and cube edges—following the scheme in [2,15]—the normal vector is component-wise mirrored into positive. (We note that in [15] in Equations (21) and (23), respectively, the “+” should be a “−” and in Equation (24) the “>” should be a “<”.) The mirrored normal vector components are sorted in ascending order according to their magnitude such that $0\le n_1\le n_2\le n_3\le 1$. Because $\overrightarrow{n}$ is normalized, the absolute value of its largest component $n_3$ is always greater than zero. In summary, the mirroring removes the sign(s) from $n_x$, $n_y$, $n_z$ and and puts them in ascending order, such that normalization still holds: $n_x^2+n_y^2+n_z^2=n_1^2+n_2^2+n_3^2=1$.

$$\begin{array}{cc}\hfill n_1& :=min\left(\right|n_x|,|n_y|,|n_z\left|\right)\ge 0\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill n_3& :=max\left(\right|n_x|,|n_y|,|n_z\left|\right)>0\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill n_2& :=|n_x|+|n_y|+|n_z|-n_1-n_3\ge 0\hfill \end{array}$$

(4)

Since the function $V_0\left(d_0\right)$ is symmetric around $d_0=0$ and increasing monotonically, the reduced-symmetry-volume $V\in [0,\frac{1}{2}]$ is limited to the lower half of the intersection volume $V_0$ and the upper half is reconstructed from symmetry.

$$\begin{array}{cc}\hfill V:=& \frac{1}{2}-\left|V_0-\frac{1}{2}\right|\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill V_0=& \mathrm{sign}\left(d_0\right)\left(\frac{1}{2}-V\right)+\frac{1}{2}\hfill \end{array}$$

(6)

This symmetry condition for the case $V_0>\frac{1}{2}$ is now applied to $d_0$, and the coordinate origin is shifted from $(0,0,0)$ (center of the unit cube) to $(-\frac{1}{2},-\frac{1}{2},-\frac{1}{2})$ (bottom left corner in the back in Figure 1), resulting in the distance $d\in [0,\frac{n_1+n_2+n_3}{2}]$ in reduced symmetry space:

$$\begin{array}{cc}\hfill d:=& \frac{n_1+n_2+n_3}{2}-\left|d_0\right|\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill d_0=& \mathrm{sign}\left(V_0-\frac{1}{2}\right)\left(\frac{n_1+n_2+n_3}{2}-d\right)\hfill \end{array}$$

(8)

With this reduction in symmetry, there are only five different intersection cases remaining (see Figure 1).

2.2. Formulating the Inverse PLIC Problem

In order to derive the analytic PLIC solution, first, the inverse problem is formulated in equations—again, following the scheme in [2]. In the inverse problem, the intersection volume is calculated from the plane offset and normal vector as inputs. At first, the intersection points $s_1$, $s_2$ and $s_3$ of the plane with the coordinate system axes (see Figure 1) are determined:

$$s_1:=\frac{d}{n_1}\ge s_2:=\frac{d}{n_2}\ge s_3:=\frac{d}{n_3}$$

(9)

Now, one calculates the actual volume in reduced symmetry space. The approach is to calculate the volume of the tetrahedral pyramid formed by the plane and the coordinate system axes and, if necessary, subtract the volumes of zero, one, two or all three corners that extend beyond 1. For case (3), an additional condition is required to mutually exclude case (5), in which the bottom four corners of the cube are located beneath the plane.

$$V=\left\{\begin{array}{cc}\frac{1}{6}{s}_1{s}_2{s}_3\hfill & \mathrm{if}{s}_1<1\hfill \\ \frac{1}{6}{s}_2{s}_3\left(s_1-(s_1-1){\left(1-\frac{1}{s_1}\right)}^2\right)\hfill & \mathrm{if}{s}_1\ge 1\mathrm{and}{s}_2\le 1\hfill \\ \frac{1}{6}{s}_3\left(s_1{s}_2-(s_1-1)s_2{\left(1-\frac{1}{s_1}\right)}^2-(s_2-1)s_1{\left(1-\frac{1}{s_2}\right)}^2\right)\hfill & \mathrm{if}{s}_2\ge 1\mathrm{and}{s}_3\le 1\hfill \\ \hfill & \mathrm{and}{s}_1(s_2-1)\le s_2\hfill \\ \frac{1}{6}\left(s_1{s}_2{s}_3-(s_1-1)s_2{s}_3{\left(1-\frac{1}{s_1}\right)}^2-(s_2-1)s_1{s}_3{\left(1-\frac{1}{s_2}\right)}^2-(s_3-1)s_1{s}_2{\left(1-\frac{1}{s_3}\right)}^2\right)\hfill & \\ \hfill & \mathrm{if}{s}_3\ge 1\hfill \\ \frac{1}{2}{s}_3\left(2-\frac{1}{s_1}-\frac{1}{s_2}\right)\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(10)

To shorten Equation (10), $s_1$, $s_2$ and $s_3$ are substituted and the expression is simplified, yielding

$$V=\frac{1}{6n_1{n}_2{n}_3}·\left\{\begin{array}{cc}{d}^3\hfill & \left(1\right)\mathrm{if}d<n_1\hfill \\ (d^3-{(d-n_1)}^3)\hfill & \left(2\right)\mathrm{if}{n}_1\le d\le n_2\hfill \\ (d^3-{(d-n_1)}^3-{(d-n_2)}^3)\hfill & \left(3\right)\mathrm{if}{n}_2\le d\le min(n_1+n_2,n_3)\hfill \\ (d^3-{(d-n_1)}^3-{(d-n_2)}^3-{(d-n_3)}^3)\hfill & \left(4\right)\mathrm{if}{n}_3\le d\hfill \\ 6n_1{n}_2(d-\frac{1}{2}(n_1+n_2))\hfill & \left(5\right)\mathrm{if}min(n_1+n_2,n_3)\le d\le n_3\hfill \end{array}\right.$$

(11)

which is already considerably more friendly and completes the inverse PLIC formulation in conjunction with Equations (2)–(4), (6) and (7). The condition for case (5) is the remaining free sector of the possible range of d mutually excluded by the other four cases. Listing A1 shows the fully optimized C implementation of the inverse PLIC solution.

2.3. Inverting the Inverse PLIC Formulation Analytically

Equation (11) is now inverted for each case individually. Cases (1), (2) and (5) are easy, but cases (3) and (4) are non-trivial third-order polynomials. Here, we make use of the tool Mathematica, which outputs three complex solutions for cases (3) and (4) each (Appendix A), of which the third solutions, respectively, are the correct ones as their imaginary parts in the desired range are zero after simplification. Luckily, both are of the same overall form (Equation (12)). However, a complex solution is not useful here since the expected result is a real number—a problem known as the casus irreducibilis—and most programming languages cannot deal with complex numbers natively. It would also lead to unwanted computational overhead to carry along the imaginary part during computation, which, in the end, will be zero anyway. To overcome this, we again make use of Mathematica to simplify the general form of the complex solution (Equation (12)) in order to obtain the real, trigonometric solution (Equation (13)):

$$\begin{array}{cc}\hfill \mathrm{f}(x,y,a,b,c):=& c-a\frac{(1-i\sqrt{3})}{\sqrt[3]{x+iy}}-b(1+i\sqrt{3})\sqrt[3]{x+iy}\hfill \end{array}$$

(12)

$$\begin{array}{cc}\hfill \mathrm{f}(x,y,a,b,c):=& c-2\frac{a+b\sqrt[3]{x^2+y^2}}{\sqrt[6]{x^2+y^2}}sin\left(\frac{\pi }{6}-\frac{1}{3}\mathrm{atan}2(y,x)\right)\hfill \end{array}$$

(13)

Equation (13) already is further simplified using the trigonometric identity $\sqrt{3}sin\left(\alpha \right)-cos\left(\alpha \right)=-2sin(\frac{\pi }{6}-\alpha )$ such that the number of trigonometric functions (which are computationally expensive compared to simpler operations such as additions or multiplications) is minimized (Equation (13)).

For better readability, a few expressions are pre-defined. Hereby, the normalization condition $n_1^2+n_2^2+n_3^2=1$ is applied.

$$\begin{array}{cc}\hfill x_3& :=81n_1{n}_2(n_1+n_2-2V{n}_3)>0\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill y_3& :=\sqrt{23328{\left(n_1{n}_2\right)}^3-x_3^2}\ge 0\hfill \end{array}$$

(15)

$$\begin{array}{cc}\hfill a_3& :=\sqrt[3]{54}{n}_1{n}_2\hfill \end{array}$$

(16)

$$\begin{array}{cc}\hfill b_3& :=\frac{1}{\sqrt[3]{432}}\hfill \end{array}$$

(17)

$$\begin{array}{cc}\hfill c_3& :=n_1+n_2\hfill \end{array}$$

(18)

$$\begin{array}{cc}\hfill t_4& :=9{(n_1+n_2+n_3)}^2-18\hfill \end{array}$$

(19)

$$\begin{array}{cc}\hfill x_4& :=324n_1{n}_2{n}_3(1-2V)\ge 0\hfill \end{array}$$

(20)

$$\begin{array}{cc}\hfill y_4& :=\sqrt{4t_4^3-x_4^2}\ge 0\hfill \end{array}$$

(21)

$$\begin{array}{cc}\hfill a_4& :=\frac{1}{\sqrt[3]{864}}{t}_4\hfill \end{array}$$

(22)

$$\begin{array}{cc}\hfill b_4& :=\frac{1}{\sqrt[3]{3456}}\hfill \end{array}$$

(23)

$$\begin{array}{cc}\hfill c_4& :=\frac{n_1+n_2+n_3}{2}\hfill \end{array}$$

(24)

Finally, then, the complete analytic solution to the 3D PLIC problem is given by

$$d=\left\{\begin{array}{cc}{d}_1=\sqrt[3]{6V{n}_1{n}_2{n}_3}\hfill & \left(1\right)\mathrm{if}{d}_1<n_1\hfill \\ d_2=\frac{n_1}{2}+\sqrt{2V{n}_2{n}_3-\frac{1}{12}{n}_1^2}\hfill & \left(2\right)\mathrm{if}{n}_1\le d_2\le n_2\hfill \\ d_3=\mathrm{f}(x_3,y_3,a_3,b_3,c_3)\hfill & \left(3\right)\mathrm{if}{n}_2\le d_3\le min(n_1+n_2,n_3)\hfill \\ d_4=\mathrm{f}(x_4,y_4,a_4,b_4,c_4)\hfill & \left(4\right)\mathrm{if}{n}_3\le d_4\hfill \\ d_5=V{n}_3+\frac{n_1+n_2}{2}\hfill & \left(5\right)\mathrm{if}min(n_1+n_2,n_3)\le d_5\le n_3\hfill \end{array}\right.$$

(25)

in conjunction with Equations (2)–(5), (8), (13)–(24).

In Equation (25), it is noteworthy that the conditions for the five different cases are determined a posteriori by the result itself. This means that each case has to be evaluated successively and, for the resulting value d, the respective condition has to be tested. If the condition is true, calculation is stopped and d is returned. If the condition is false, the next case has to be evaluated and so on, until the last case is reached.

The order in which the cases are computed and checked can be optimized to calculate the most difficult and infrequent cases last, when the probability is high that one of the easier and more frequent cases has already been chosen. ‘Frequent’ here refers to some cases appearing more often than others with randomized $V_0$ and $\overrightarrow{n}$, as expected in typical PLIC applications. Here, special considerations for edge cases (more on this below) also need to be taken into account to avoid possible divisions by zero. With this in mind, the order $\left(5\right)\to \left(2\right)\to \left(1\right)\to \left(3\right)\to \left(4\right)$ is preferred.

Additional speedup can be gained by noting that the implicit condition involving d can be replaced by an explicit condition involving V for cases (1), (2) and (5):

$$d=\left\{\begin{array}{cc}{d}_1=\sqrt[3]{6V{n}_1{n}_2{n}_3}\hfill & \left(1\right)\mathrm{if}6V{n}_2{n}_3<n_1^2\hfill \\ d_2=\frac{n_1}{2}+\sqrt{2V{n}_2{n}_3-\frac{1}{12}{n}_1^2}\hfill & \left(2\right)\mathrm{if}3n_2(V{n}_3+n_1-n_2)\le n_1^2\le 6V{n}_2{n}_3\hfill \\ d_3=\mathrm{f}(x_3,y_3,a_3,b_3,c_3)\hfill & \left(3\right)\mathrm{if}{n}_2\le d_3\le min(n_1+n_2,n_3)\hfill \\ d_4=\mathrm{f}(x_4,y_4,a_4,b_4,c_4)\hfill & \left(4\right)\mathrm{if}{n}_3\le d_4\hfill \\ d_5=V{n}_3+\frac{n_1+n_2}{2}\hfill & \left(5\right)\mathrm{if}{n}_1+n_2\le 2V{n}_3\hfill \end{array}\right.$$

(26)

Since V is known, these conditions are checked a priori in order to avoid root function calls if the condition is false.

For even more speedup, all redundant mathematical operations are reduced to a minimum by pre-calculating them to variables (micro-optimization), and condition checks mutually excluded by previous checks are skipped, especially all conditions for the very last case. In the implementation order $\left(5\right)\to \left(2\right)\to \left(1\right)\to \left(3\right)\to \left(4\right)$, the conditions for case (3) simplify to $d_3\le n_3$, which will mutually exclusively decide between cases (3) and (4). Since both $d_3$ and $d_4$ are very complicated expressions, here, no simplified a priori condition is formulated.

In Equations (19), (21) and (25), the argument of the square root may be negative before the case condition is tested. In this case—since, in the actual code, floating-point exception handling is turned off for performance reasons—the resulting NaN of a square root of a negative number would not be captured in the case condition, leading to an incorrect result. An additional fdim function call in the square root solves this issue. In the implementation, we artificially exclude the edge case $x_4=0$ in order to, instead of $\mathrm{atan}2(y,x)$, use the faster $\mathrm{atan}(y/x)$, giving the algorithm a $15\%$ speedup. In case branching would be undesirable, bit masking is also an option, but bit masking turned out to be slower even on GPUs.

Two edge cases still need to be taken into careful consideration: $n_1=0$ (2D) and $n_3=1$ (1D). $n_1=0$ restricts $\overrightarrow{n}$ to be in a 2D plane of two coordinate system axes and $n_3=1$ restricts $\overrightarrow{n}$ to be parallel to one of the coordinate system axes. For the (1D) case, $n_3=1$ and the solution is always (5), so $n_1=n_2=0$ and $min(n_1+n_2,n_3)=0$, simplifying Equation (25) without loss of generality to

$$d=\{\begin{array}{cc}V\hfill & \left(5\right)\mathrm{if}0\le d\le 1\hfill \end{array}$$

(27)

A clean derivation of the 1D case yields

$$d=V$$

(28)

without any conditions, so it is a necessary requirement that both additional conditions in Equation (27) must be fulfilled automatically. d is in the range $0\le d\le \frac{n_1+n_2+n_3}{2}$, so, here, in the special case, we have $0\le d\le \frac{0+0+1}{2}=\frac{1}{2}\le 1$, which means that $0\le d\le 1$ is indeed fulfilled automatically.

In the (2D) case, $n_1=0$ ($n_2=0$ is excluded here since it is already covered in the (1D) case, so here $n_2>0$). Here, only intersection cases (2) or (5) are possible, $0<n_2\le n_3\le 1$ and $min(n_1+n_2,n_3)=n_2$, simplifying Equation (25) without loss of generality to

$$d=\left\{\begin{array}{cc}\sqrt{2V{n}_2{n}_3}\hfill & \left(2\right)\mathrm{if}0\le d\le n_2\hfill \\ V{n}_3+\frac{n_2}{2}\hfill & \left(5\right)\mathrm{if}{n}_2\le d\le n_3\hfill \end{array}\right.$$

(29)

A clean derivation of the 2D case yields

$$d=\left\{\begin{array}{cc}\sqrt{2V{n}_2{n}_3}\hfill & \left(2\right)\mathrm{if}d\le n_2\hfill \\ V{n}_3+\frac{n_2}{2}\hfill & \left(5\right)\mathrm{if}{n}_2\le d\hfill \end{array}\right.$$

(30)

which has simpler conditions, so again it is a necessary requirement that both additional conditions in Equation (29) must be fulfilled automatically. d is in the range $0\le d\le \frac{n_1+n_2+n_3}{2}$, so here, with the special conditions, we have $0\le d\le \frac{0+n_2+n_3}{2}\le \frac{n_3+n_3}{2}=n_3$, meaning that both $0\le d$ and $d\le n_3$ are indeed fulfilled automatically.

In the above chosen $\left(5\right)\to \left(2\right)\to \left(1\right)\to \left(3\right)\to \left(4\right)$ implementation order, the 1D and 2D special cases are already covered in (5) and (2) at the beginning, so they both are excluded in the remaining intersection cases (1), (3) and (4), meaning that $n_1,n_2,n_3>0$ are always given, resulting in $x_3>0$ in Equation (14).

Listing A2 shows the fully optimized C implementation of the analytic PLIC solution with Equation (26).

2.4. The Analytic SZ Solution

The analytic PLIC solution by Scardovelli and Zaleski from 2000 [4] was implemented in Fortran in 2016 by Kawano [5], where it was used as a comparison to the approximative APPLIC method. Here, we focus on the exact SZ solution. The SZ solution is particularly interesting in that it builds upon the $L_1$-normalized plane normal vector, instead of the more common $L_2$ normalization as used in our own solution in Section 2.3. We first translate the Fortran implementation to C, make it compatible with an $L_2$-normalized plane normal vector as input and rescale the result from the original $[0,1]$ to $[-\frac{|n_x|+|n_y|+|n_z|}{2},\frac{|n_x|+|n_y|+|n_z|}{2}]$. The implementation is provided in Listing A3.

To summarize, the differences between our novel solution and the SZ Kawano implementation are the following:

• while our solution is based on the $L_2$-normalized plane normal vector, the SZ solution uses the $L_1$-normalized normal vector;
• our solution takes two atan operations while the SZ solution takes one acos operation;
• our solution has a smaller number of arithmetic operations and branching than the SZ Kawano implementation, but requires more special functions.

When closely studying the implementation in Listing A3, we notice that the 1D edge case is poorly handled despite the addition of a tiny constant to the denominator for the calculation of v1. In the edge cases of the normal vector $\overrightarrow{n}={(1,0,0)}^{\mathrm{T}}$ and the volume $V_0\in \{0,1\}$, the algorithm returns -NaN both in our OpenCL and in the original Fortran implementation. By checking cases (5) and (2) first and by avoiding divisions by vm1 and vm2 before the checks for cases (5) and (2), respectively, we improve the handling of the 1D edge case. We further apply some micro-optimization to significantly reduce the number of arithmetic operations and branching.

With the knowledge gained from our novel PLIC solution, we are able to make the following improvements to the existing SZ Kawano implementation, resulting in an optimized implementation of the SZ solution as shown in Listing A4:

• correct edge case behavior;
• more efficient branching by computing easier, more common cases first and less common, more computationally expensive cases last;
• micro-optimization by pre-computing redundant terms and minimizing the number of arithmetic operations and branching.

2.5. Iterative Solutions

For comparison, we also provide iterative solutions using nested intervals in Listing A5 and Newton–Raphson in Listing A6.

2.6. Performance and Accuracy Comparison

Apart from floating-point errors, the SZ solution in Listing A4 and our own solution in Listing A2 produce identical results. For accuracy comparison, we define the error as

$$E_i:=|\mathrm{plic}\_\mathrm{cube}\_\mathrm{inverse}(\mathrm{plic}\_\mathrm{cube}(V_0,{\overrightarrow{n}}_i),{\overrightarrow{n}}_i)-V_0|$$

(31)

with $\mathrm{plic}\_\mathrm{cube}\_\mathrm{inverse}(d_0,{\overrightarrow{n}}_i)$ referring to the implementation in Listing A1 and $\mathrm{plic}\_\mathrm{cube}(V_0,{\overrightarrow{n}}_i)$ referring to the various PLIC implementations. We define the average error as follows:

$$\begin{array}{cc}\hfill E_{\mathrm{avg}}& :=\frac{1}{NL}\sum _{i=0}^{NL-1}\left(E_i\right)\hfill \end{array}$$

(32)

The execution time for a ‘blank run’

$$E_{i,\mathrm{blank}}:=|\mathrm{plic}\_\mathrm{cube}\_\mathrm{inverse}(V_0-\frac{1}{2},{\overrightarrow{n}}_i)-V_0|$$

(33)

containing the time for memory loads and stores as well as computing time for the inverse PLIC algorithm is measured and later subtracted from the execution times of the different PLIC variants in order to isolate their execution time. The time is also divided by the number of PLIC function evaluations $\left(NL\right)$ in order to obtain the time for a single execution.

Table 1. Number of operations counted from C code. Arithmetic operations contain all floating-point and integer operations except for those listed separately. For nested intervals, $k\approx 20$ denotes the number of iterations until sufficient convergence.

PLIC Variant	Arithmetic Ops	Branching	$\frac{1}{\sqrt{\mathit{x}}}$	$\sqrt{\mathit{x}}$	$\sqrt[3]{\mathit{x}}$	sin/cos	asin/acos	atan
Listing A2 our solution	95	4	2	3	3	2		2
Listing A3 SZ Kawano	123	6		2	1	1	1
Listing A4 SZ optimized	97	3		2	1	1	1
Listing A5 nested intervals	$750(70+34k)$	$44(4+2k)$		1	1
Listing A6 Newton-Raphson	308	4		1

classifies the different PLIC algorithms based on the number and type of operations. Iterative solutions trade special functions (square/cube roots and trigonometric functions) for a larger number of additions and multiplications.

2.6.1. CPU Testing

In this test, ${\overrightarrow{n}}_i$ is set to $N=4096$ different normal vectors, of which one is ${(1,0,0)}^{\mathrm{T}}$, one is ${(\frac{1}{\sqrt{2}},\frac{1}{\sqrt{2}},0)}^{\mathrm{T}}$, 510 are random 2D directions in the x-y-plane and the remaining 3584 are random 3D directions. For each of these, the volume $V_0$ is varied in the interval $[0,1]$—edge cases included—in $L=4096$ equally spaced steps. The test is executed on a single core of a Coffee Lake Intel Core i7-8700K CPU at $4.5\mathrm{GHz}$ non-AVX2 and $4.0\mathrm{GHz}$ AVX2 clock frequency with the MSVC C++ compiler. The tests run only on a single CPU core. We cover three scenarios with different compiler flags.

Firstly, we test without any compiler optimization (/Od, /Qpar-). The execution time results are very different, as shown in

Table 2. Comparison of execution time and accuracy of the different PLIC variants with compiler optimizations disabled.

PLIC Variant	Execution Time/ns	${\mathit{E}}_{\mathbf{avg}}$
Listing A2 our analytic solution	$40.1\pm 7.9$	$2.04\times {10}^{-8}$
Listing A3 SZ solution by Kawano	$51.3\pm 8.3$	$-\mathrm{NaN}$
Listing A4 SZ solution optimized	$35.6\pm 11.4$	$4.70\times {10}^{-8}$
Listing A5 nested intervals	$416.7\pm 19.5$	$2.62\times {10}^{-8}$
Listing A6 Newton-Raphson	$49.3\pm 7.6$	$1.70\times {10}^{-8}$

. All variants but the Kawano implementation and nested intervals are within the margin of error regarding computing time. In the edge cases of the normal vector $\overrightarrow{n}={(1,0,0)}^{\mathrm{T}}$ and the volume $V_0\in \{0,1\}$, the SZ solution by Kawano returns -NaN, which propagates through the entire error averaging procedure. For the IEEE-754 FP32 floating-point format, the machine epsilon is at $ϵ=5.96\times {10}^{-8}$, meaning that, for all other PLIC variants, the average error $E_{\mathrm{avg}}$ is within machine precision.

Secondly, we repeat the test with compiler optimizations enabled, but with AVX2 disabled. The used compiler flags are /O2, /Oi, /Ot, /Qpar- and /fp:except-. The results are presented in

Table 3. Comparison of execution time and accuracy of the different PLIC variants with compiler optimizations enabled but AVX2 auto-vectorization disabled.

PLIC Variant	Execution Time/ns	${\mathit{E}}_{\mathbf{avg}}$
Listing A2 our analytic solution	$33.0\pm 5.1$	$2.04\times {10}^{-8}$
Listing A3 SZ solution by Kawano	$36.6\pm 5.1$	$-\mathrm{NaN}$
Listing A4 SZ solution optimized	$35.3\pm 7.0$	$4.70\times {10}^{-8}$
Listing A5 nested intervals	$266.0\pm 11.2$	$2.62\times {10}^{-8}$
Listing A6 Newton-Raphson	$10.6\pm 5.8$	$1.70\times {10}^{-8}$

. Here, Newton–Raphson considerably outperforms all the other solutions.

Lastly, we test with full compiler optimizations and AVX2. The used compiler flags are /O2, /Oi, /Ot, /Qpar, /arch:AVX2 and /fp:except-. The results are presented in

Table 4. Comparison of execution time and accuracy of the different PLIC variants with compiler optimizations enabled and with AVX2 auto-vectorization allowed.

PLIC Variant	Execution Time/ns	${\mathit{E}}_{\mathbf{avg}}$
Listing A2 our analytic solution	$37.0\pm 8.2$	$2.04\times {10}^{-8}$
Listing A3 SZ solution by Kawano	$37.2\pm 3.6$	$-\mathrm{NaN}$
Listing A4 SZ solution optimized	$35.6\pm 5.3$	$4.70\times {10}^{-8}$
Listing A5 nested intervals	$252.2\pm 8.7$	$2.62\times {10}^{-8}$
Listing A6 Newton-Raphson	$9.6\pm 3.1$	$1.70\times {10}^{-8}$

. In all variants, execution times do not significantly differ from when AVX is disabled, indicating that auto-vectorization is not being applied at all. As an additional indicator, the CPU clock frequency does not drop by the AVX2 clock offset while the tests are running.

2.6.2. GPU Testing

Since, in many applications, the target platform for the PLIC algorithm is the GPU, we also benchmark the different variants in OpenCL on an Nvidia Titan Xp GPU (3840 CUDA cores at $1582\mathrm{MHz}$, $12.1\mathrm{TFLOPs}/\mathrm{s}$, driver version $442.59$, OpenCL $1.2$). The test here differs from the CPU C++ test in that, for sufficient saturation of the parallel computing capabilities, the number of random normal vectors is increased to 67,108,864, of which again one is ${(1,0,0)}^{\mathrm{T}}$, one is ${(\frac{1}{\sqrt{2}},\frac{1}{\sqrt{2}},0)}^{\mathrm{T}}$, 8,388,606 are random 2D directions in the x-y-plane and the remaining 58,720,256 are random 3D directions. For these normal vectors, PLIC is run in parallel and, for each of them, the volume $V_0$ is varied in the interval $[0,1]$—edge cases included—in $L=256$ equally spaced steps in series. For more accurate results through averaging, this test is run 64 times and the mean execution time is averaged and divided by the number of parallel and serial PLIC computations, resulting in an average computing time that is more than three magnitudes shorter than for single-core CPU execution, as listed in

Table 5. Comparison of execution time and accuracy of the different PLIC variants in OpenCL on a GPU.

PLIC Variant	Execution Time/ps	${\mathit{N}}_{\mathit{a}}$	${\mathit{N}}_{\mathit{b}}$	TFLOPs/s	${\mathit{E}}_{\mathbf{avg}}$
Listing A2 our analytic solution	$19.0\pm 1.7$	189	13	$9.9$	$5.73\times {10}^{-8}$
Listing A3 SZ solution by Kawano	$16.0\pm 1.5$	149	14	$9.3$	$-\mathrm{NaN}$
Listing A4 SZ solution optimized	$12.8\pm 1.0$	132	12	$10.3$	$6.58\times {10}^{-8}$
Listing A5 nested intervals	$106.4\pm 6.2$	106	13	$10.0$	$2.86\times {10}^{-8}$
Listing A6 Newton-Raphson	$19.2\pm 1.8$	256	11	$13.3$	$5.47\times {10}^{-8}$

. Even though the tests are designed differently for the CPU and GPU, this comparison is appropriate because, in both cases, the same algorithms are computed and the hardware is fully saturated. The table also includes the number of arithmetic operations (floating-point, integer and bit operations combined) $N_a$ and the number of branching operations $N_b$ in PTX assembly [37]. GPUs are especially poor at branching, so a small $N_b$ is desired. These operation counts—in analogy to the computing time—refer to the isolated PLIC variants with the background ‘blank run’ for memory loads and stores as well as the inverse PLIC algorithm subtracted. $N_a$ indicates that Newton–Raphson is unrolled by the compiler, whereas nested intervals are not. The number of iterations to reach machine precision for nested intervals depends on the initial interval width, which is a function of the normal vector components. For Newton–Raphson, the number of branching operations $N_b$ is the smallest, resulting in rather good performance. Nevertheless, our optimized implementation of the SZ solution pulls ahead rather significantly and thus is preferred by us.

By dividing $N_a$ by the execution time, we obtain the performance in TFLOPs/s (integer and bit operations are included since these are performed on the same CUDA cores as floating-point operations on Nvidia Pascal), showing that computing efficiency is not significantly impacted by the special functions used in the analytic solutions.

It is noteworthy that there also is a novel neural network-based approach termed NPLIC that promises significant speedup, especially for more complex, non-cubic lattices [38]. This approach efficiently works on GPU hardware by using mainly multiplication and addition.

3. Application: Curvature Calculation for VoF-LBM on the GPU

3.1. Volume-of-Fluid Overview

Volume-of-Fluid (VoF) is a model to simulate a sharp, freely moving interface between a fluid and gas phase in a Cartesian lattice [9,10,11,12]. While it can be coupled to any flow solver, here, we focus on its usage in conjunction with the lattice Boltzmann method (LBM). The interface is ensured to be exactly one lattice cell thick at any time (illustrated in Figure 2). As an indicator for each lattice point type, the fill level $\phi$ is introduced, whereby, for fluid lattice points $\phi =1$, for interface$1>\phi >0$ and for gas$\phi =0$:

$$\phi (\overrightarrow{x},t):=\frac{m(\overrightarrow{x},t)}{\rho (\overrightarrow{x},t)}\left\{\begin{array}{cc}=1\hfill & \mathrm{if}\overrightarrow{x}\mathrm{is}fluid\hfill \\ \in ]0,1[\hfill & \mathrm{if}\overrightarrow{x}\mathrm{is}interface\hfill \\ =0\hfill & \mathrm{if}\overrightarrow{x}\mathrm{is}gas\hfill \end{array}\right.$$

(34)

Here, $\rho$ is the density provided by the lattice Boltzmann method (LBM) and m is the fluid mass. m is a conserved quantity and cannot be gained or lost, only moved within the simulation box. Isolated interface cells are not allowed to exist. If an interface cell has no fluid neighbors, it is converted to gas. Its remaining mass is distributed as excess mass to neighboring interface cells. The details are described in [8].

The key difficulty of modeling a free surface on a discretized lattice is to obtain the surface curvature, which is a necessary ingredient for calculating the surface tension via the Young–Laplace pressure

$$\Delta p=2\sigma \kappa$$

(35)

with $\kappa =\frac{1}{R}$ denoting the local mean curvature and $\sigma$ denoting the surface tension parameter of the simulated fluid. The equation is easy in principle, but calculating $\kappa$ from the discretized interface geometry is not. Specifically, discretized interface here means that only a local $3^3$ neighborhood of fill levels $\phi \in [0,1]$ is known, in addition to the point in the center of this neighborhood being an interface lattice point.

$${\phi }_0,\cdots ,{\phi }_{26}\to \kappa$$

(36)

The most common algorithm in the literature [9,12] is the curvature calculation via a least-squares paraboloid fit from a neighborhood of points located on the interface. It assumes the local interface to be a paraboloid, the specifics of which will be given in the following sections. Finding an appropriate set of neighboring points on the interface requires the PLIC solution.

3.2. Obtaining Neighboring Interface Points: PLIC Point Neighborhood

Piecewise linear interface construction works on a $3^3$ neighborhood of an interface lattice point (illustrated in 2D in Figure 3a). Within this neighborhood, only interface points other than the center interface point—which is always interface—are considered as candidates for the later fitting procedure (Figure 3b). The difficult part is to accurately obtain the heights $z_i$ of at least five neighboring points located on the true interface (Figure 3c). For this, first, the normal vector $\overrightarrow{n}$ of the center interface point is calculated via the Parker–Youngs approximation as described in the Appendix C.1 in Equation (A4). A new coordinate system is introduced, with its first base vector ${\overrightarrow{b}}_z$ defined as this normal vector. Then, the cross product with an arbitrary vector such as

$$\overrightarrow{r}:={(0.56270900,0.32704452,0.75921047)}^{\mathrm{T}}$$

(37)

which is always non-colinear with ${\overrightarrow{b}}_z$ by random chance is calculated to provide second and third orthonormal vectors

$$\begin{array}{cc}\hfill {\overrightarrow{b}}_z& :=\overrightarrow{n}\hfill \end{array}$$

(38)

$$\begin{array}{cc}\hfill {\overrightarrow{b}}_y& :=\frac{{\overrightarrow{b}}_z\times \overrightarrow{r}}{|{\overrightarrow{b}}_z\times \overrightarrow{r}|}\hfill \end{array}$$

(39)

$$\begin{array}{cc}\hfill {\overrightarrow{b}}_x& :={\overrightarrow{b}}_y\times {\overrightarrow{b}}_z\hfill \end{array}$$

(40)

forming the new coordinate system in which the z-axis is colinear with the surface normal and the center interface point is in the origin. Now, the relative positions ${\overrightarrow{e}}_i$ of all neighboring interface lattice points (equal to the D3Q27 LBM streaming directions, Equation (A2)) are gathered and transformed into the rotated coordinate system. During this step, the approximate interface position of neighboring interface points (streaming directions, Figure 3b) is corrected to the much more accurate interface position via the PLIC plane–cube intersection solution (Section 2, Figure 3c,d):

$${\overrightarrow{p}}_i=\left(\begin{array}{c}{x}_i\\ y_i\\ z_i\end{array}\right):=\left(\begin{array}{c}{\overrightarrow{e}}_i·{\overrightarrow{b}}_x\\ {\overrightarrow{e}}_i·{\overrightarrow{b}}_y\\ {\overrightarrow{e}}_i·{\overrightarrow{b}}_z+d_0({\phi }_i,\overrightarrow{n})-d_0({\phi }_0,\overrightarrow{n})\end{array}\right)$$

(41)

Here, i is only the subset of $\{0,\dots ,26\}$ for which $0<{\phi }_i<1$ is true (interface points). $d_0(V_0={\phi }_i,\overrightarrow{n})$ denotes the PLIC function (Equation (8)). Note that $d_0(V_0={\phi }_0,\overrightarrow{n})$ only needs to be calculated once, while $d_0(V_0={\phi }_i,\overrightarrow{n})$ has to be calculated for each neighboring interface point, and that the normal vectors of neighboring interface lattice points are approximated to be equal to the normal vector of the center lattice point. In theory, going with the separately calculated neighbor normal vectors—which would require either an additional data buffer for normal vectors in memory or alternatively a $5^3$ neighborhood, which would break the multi-GPU capabilities of the code—should be more accurate, but our practical tests indicated no significant difference (see Figure 4).

The set of points ${\overrightarrow{p}}_i$ is then used to fit a local paraboloid. This paraboloid (Figure 3e) here lacks a vertical offset parameter as that is handled already by the center point being defined as the origin, reducing the computational cost to an LU decomposition of dimensionality $N=5$. The paraboloid has the form

$$z(x,y)=A{x}^2+B{y}^2+Cxy+Hx+Iy=:\overrightarrow{x}·\overrightarrow{Q}$$

(42)

with

$$\begin{array}{cc}\hfill \overrightarrow{x}& :={(A,B,C,H,I)}^{\mathrm{T}}\hfill \end{array}$$

(43)

$$\begin{array}{cc}\hfill \overrightarrow{Q}& :={(x^2,y^2,xy,x,y)}^{\mathrm{T}}\hfill \end{array}$$

(44)

The solution vector $\overrightarrow{x}$ and thus the fitting parameters are calculated following the procedure in Appendix C.3. Finally, the constants A, B, C, H and I are inserted into the analytic equation for the curvature (A13), completing the algorithm.

3.3. Validating Curvature Calculation

To test the accuracy of the presented curvature calculation method, we validate it on spherical drops of different radius $R=\frac{1}{{\kappa }_{\mathrm{theo}}}$. The fill levels $\phi$ are initialized with the inverse PLIC algorithm. To let the drop relax and the error converge, we simulate up to 50,000 LBM time steps with D3Q19 SRT ($\tau =1$, $\sigma =0.001$). The curvature error is calculated using the $L_1$ error norm with summation over all interface points:

$$E\left(\kappa \right):=\frac{\sum |{\kappa }_{\mathrm{sim}}-{\kappa }_{\mathrm{theo}}|}{\sum {\kappa }_{\mathrm{theo}}}$$

(45)

We plot the error in Figure 4. For low drop radius $R\le 32$, the error of our proposed method (red curve) is around $0.5\%$ and the local distribution of the error on the sphere is very homogeneous (Figure 5). As R is increased, the error also generally increases and points with particularly large errors emerge on the sphere surface. This can be assuming that ${\kappa }_{\mathrm{sim}}$ is accurate to some statistically distributed error $ϵ$, ${\kappa }_{\mathrm{sim}}={\kappa }_{\mathrm{theo}}\pm ϵ$. When $ϵ$ remains independent of R, the relative error $\frac{|{\kappa }_{\mathrm{sim}}-{\kappa }_{\mathrm{theo}}|}{{\kappa }_{\mathrm{theo}}}=ϵR$ will increase proportionally with R. The curvature-independent error $ϵ$ in turn arises from the so-called staircase effect, in which the numerical curvature of a flat plane is non-zero if the plane is not aligned with one of the coordinate axes. In Figure 6, we demonstrate this effect quantitatively.

If we do not make the assumption that the PLIC normal direction of neighbor interface points has to equal the center normal vector (orange curve), then accuracy is slightly improved. However, the additional computational complexity may not justify this small improvement in accuracy.

For comparison, we also plot the curvature approximation method proposed by Donath [17] without and with the proposed $\frac{\pi }{4}$ correction factor. As expected, the error is much larger, but this method is also computationally less expensive than ours and certainly has its use-cases as well.

3.4. Application Example: Simulating a Terminal Velocity Raindrop Impact

The analytic plane–cube intersection solution presented in this work has originally been developed for the VoF-LBM GPU simulation code FluidX3D, where we could observe a significant speedup compared to when an iterative nested-intervals solution is used. To illustrate this particular application of PLIC, we show a simulation of a $5\mathrm{mm}$ diameter raindrop impact at terminal velocity in Figure 7. The parameters for this simulation are $\nu =1.307\times {10}^{-6}\frac{{\mathrm{m}}^2}{\mathrm{s}}$, $\rho =999.7\frac{\mathrm{kg}}{{\mathrm{m}}^3}$, $\sigma =74.2\times {10}^{-3}\frac{\mathrm{kg}}{{\mathrm{s}}^2}$, $g=9.81\frac{\mathrm{m}}{{\mathrm{s}}^2}$, $d=0.005\mathrm{m}$, $u=9.2\frac{\mathrm{m}}{\mathrm{s}}$, resulting in the dimensionless numbers $\mathit{Re}=35195$, $\mathit{We}=5702$, $\mathit{Fr}=41.54$, $\mathit{Ca}=0.1620$, $\mathit{Bo}=3.3042$. The simulation box has the dimensions $5.00\mathrm{cm}\times 5.00\mathrm{cm}\times 4.25\mathrm{cm}$ and the pool height is $2.00\mathrm{cm}$. The simulation code FluidX3D is documented in great detail in [8]. A large-scale computational study on these raindrop impact simulations was conducted in [6], alongside extensive validation of the method, showing very good agreement with experiments. At this large Reynolds number, there is only a small gap of possible LBM unit parametrization to have stable simulations and only the SRT collision operator remains stable; details can be found in SI Section S3 in [6].

The $t=0.005\mathrm{s}$ of computed time is equivalent to 4907 LBM time steps at $400\times 400\times 340$ lattice resolution. Computing time with a Nvidia Titan Xp GPU is $59.7\mathrm{s}$ with our optimized version of the SZ solution (Listing A4). When removing PLIC from the LBM algorithm, computing time is $51.2\mathrm{s}$, meaning that $14.3\%$ of the entire computing time is spent on the PLIC routine. This fraction of course depends on the simulation itself and the amount of surface area where curvature is computed, but it should give an impression of the significance of an efficient PLIC implementation for computing time. For comparison, with nested intervals (Listing A5), the total computing time for the raindrop increases to $68.0\mathrm{s}$, so this PLIC routine would take $32.8\%$ of the total computing time.

4. Conclusions

We derived an analytic solution to the PLIC problem and compared it to the existing solution by Scardovelli and Zaleski [4] in two variants: an implementation by Kawano [5] and an improved and micro-optimized version thereof. We furthermore compared these three analytic solutions to two iterative solutions using Newton–Raphson and nested intervals. We provide C implementations of all variants as well as the inverse PLIC formulation.

We observe that, in a benchmark scenario with compiler optimization on the CPU, the Newton–Raphson solution (Listing A6) is considerably faster than all other solutions. Without compiler optimization, execution times for our novel solution and our optimized version of the SZ solution are both faster than Newton–Raphson.

On the GPU, the analytic solutions are faster than the iterative solutions, with our micro-optimized version of the SZ solution as presented in Listing A4 being fastest. For a generic PLIC problem, this is the solution we recommend.

In the most common application of PLIC—curvature calculation for Volume-of-Fluid LBM, which we presented and also validated on spherical drops—profiling revealed PLIC to be the main bottleneck regarding computing time. Here, our proposed fast PLIC solution led to significant speedup of VoF calculations. We hope that our findings will also make other simulation codes more computationally efficient.