lbmpy issueshttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues2024-01-17T13:44:32+01:00https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/42Improved modelling of Boundary Conditions2024-01-17T13:44:32+01:00Markus HolzerImproved modelling of Boundary ConditionsThe development and implementation of new boundary conditions is often times complicated in lbmpy. This issue should document problems that people face with implementing boundary conditions and should therefore function as a blueprint to...The development and implementation of new boundary conditions is often times complicated in lbmpy. This issue should document problems that people face with implementing boundary conditions and should therefore function as a blueprint to improve this situation. As a first part, information that is often needed (but hard to extract in lbmpy) should be listed.
1. **Equilibrium:** For many boundary conditions (UBB, Pressure, InterpolationBB) the equilibrium near to the wall needs to be computed. This is not trivial, because usually the equilibrium is given direction-wise in lbmpy thus a simple, and ugly solution is to use a large if cascade over with the direction index.
2. **Shear stress, drag etc:** Wall models often need to take the shear drag. This goes into the same direction as the first point. Basically, it is important to be able to easily obtain the PDF values next to the wall to implement equations calculating this information.
3. **Wall distance:** For wall models and interpolation boundary conditions, the distance to the wall needs to be known
4. **Normal direction:** It should be easy, to obtain the normal direction to the wall (see: FreeSlip BC etc)
5. **Second neighbour:** For more complex BC, more fluid cells needs to be taken into account (see: NoSlipLinearBouzidi). This might lead to complications for refinement algorithms etc.
6. **Information from previous timesteps:** Some interpolation BC, need PDFs from precious timesteps (see: ExtrapolationOutflow)
7. **Optimisation methods:** Especially wall models, often rely on Newton steps to fit a certain velocity profile. Without `While` loops these can only be implemented by unrolling a fixed number of iterations
Furthermore, as stated in the book by Tim Krüger: "Despite the large number of methods available, all LB boundary conditions
for straight boundaries belong to one of two groups: link-wise and wet-node". At the moment, all boundaries are formulated link-wise. While wet-node BC might not be superior they still make some problems easier to formulate and providing a good interface to support both would be easier for users who are more familiar with one or the other.https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/28More precision problems2023-06-01T13:56:43+02:00Markus HolzerMore precision problemsWhen python numbers enter the derivation process of the LBM in one way or the other it is still quite problematic in terms of precision. For example, the following case could occur when passing `omega = 1.8`:
```python
>>> a = 1.8
>>> b...When python numbers enter the derivation process of the LBM in one way or the other it is still quite problematic in terms of precision. For example, the following case could occur when passing `omega = 1.8`:
```python
>>> a = 1.8
>>> b = sp.Rational(4, 9) * a
>>> b.evalf(17)
0.79999999999999993
```
The reason for this behaviour is that 1.8 gets converted to `sympy.Float`. This class by default assumes 15 digits of precision. I do not see an easy way to increase the precision globally. Thus numerical problems enter the derivation which will not vanish anymore.
Two possible solutions:
1. Ban numbers normal numbers completely. What this means is that all numbers which enter any top-level function of lbmpy should be mapped to a symbol which is then used instead. In the end this mapping will be added in front of the subexpressions. This should not be too hard to achieve since steps in this direction have been made already because symbols heavily simplify the derivation process in generall.
2. Rewrite all numbers as rationals. For example
```python
>>> a = 1.8
>>> b = sp.nsimplify(a)
>>> c = sp.Rational(4, 9) * b
>>> c.evalf(17)
0.8
```
This approach has the advantage that nice simplifications as above will be executed directly. With rationals, we should basically end up with integer calculations, thus precision should not play a role anymoreMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/40Communication with inplace streaming and Free Slip BC does not work2023-04-09T10:12:42+02:00Markus HolzerCommunication with inplace streaming and Free Slip BC does not workIn the `LBMPeriodicityHandling` class the slices for the communication get trimmed: https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/advanced_streaming/communication.py#L141
This ensures that the communication with advanced ...In the `LBMPeriodicityHandling` class the slices for the communication get trimmed: https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/advanced_streaming/communication.py#L141
This ensures that the communication with advanced streaming patterns works correctly and no wrong information is communicated. However, when a FreeSlip BC and a periodic wall share a side different PDFs have to be communicated (due to the different access patterns of Bounce Back and Free Slip) This is handled wrong at the moment.
A hotfix for the pull pattern was introduced !141Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/30Inconsistent normal directions in boundary conditions2023-04-05T16:36:47+02:00Daniel BauerInconsistent normal directions in boundary conditionsBoth the [`ExtrapolationOutflow`](https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/boundaries/boundaryconditions.py#L397) and the [`FreeSlip`](https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/boundaries/boundaryco...Both the [`ExtrapolationOutflow`](https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/boundaries/boundaryconditions.py#L397) and the [`FreeSlip`](https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/boundaries/boundaryconditions.py#L116) boundary conditions require a normal direction.
Currently, the normal direction in the outflow condition has to point from the fluid to the wall (in the direction of flow) while the normal direction for the free slip condition has to point from the wall to the fluid.
It would be nice if the normals would have a consistent direction.
Alternatively, the direction (wall to fluid / fluid to wall) could be specified explicitly together with the direction vector.https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/39Forcing is handled incorrectly when using a compressible equilibrium2023-01-26T10:14:05+01:00Christoph SchwarzmeierForcing is handled incorrectly when using a compressible equilibriumForcing terms are currently used incorrectly when using the compressible form of the PDF's equilibrium in `lbmpy`.
In LBM, we want the user to specify the variable `force` in terms of a body force density vector $\boldsymbol{F}$.
In the...Forcing terms are currently used incorrectly when using the compressible form of the PDF's equilibrium in `lbmpy`.
In LBM, we want the user to specify the variable `force` in terms of a body force density vector $\boldsymbol{F}$.
In the compressible case, is should be formally $\boldsymbol{F}(\boldsymbol{x},t) = \rho(\boldsymbol{x},t) \boldsymbol{a}$, where $\rho(\boldsymbol{x},t)$ is the density and $\boldsymbol{a}$ is an acceleration. I assume that $\boldsymbol{a}$ is constant in the whole domain, as I could not find a counter example where this is not the case. In contrast, I assume $\rho(\boldsymbol{x},t)$ to depend on the position $\boldsymbol{x}$ and time $t$ because that's what one observes in compressible fluids.
In `lbmpy`, such a compressible case is currently treated as follows:
1. A user can only specify the body force density $\boldsymbol{F} = \text{const.}$, which is a single vector and independent of $\boldsymbol{x}$ or $t$. Let us assume that $\rho(\boldsymbol{x},0) = 1$. During the simulation, $\rho(\boldsymbol{x},t)$ will eventually change because of the flow dynamics.
2. In `conservedquantitycomputation.py`, line 240, the macroscopic velocity for constructing the equilibrium, is shifted by $\boldsymbol{F}/2/\rho(\boldsymbol{x},t)$. The density is indeed taken dependent on $\boldsymbol{x}$ and $t$ here. Since the user has specified a force density independent of $\boldsymbol{x}$ and $t$, `lbmpy` essentially assumes that the acceleration $\boldsymbol{a}$ varies with $\boldsymbol{x}$ and $t$: We have $\boldsymbol{F} = \text{const.} = \rho(\boldsymbol{x},0) \boldsymbol{a}$. Therefore, if $\boldsymbol{F} / \rho(\boldsymbol{x},t)$ with $\rho(\boldsymbol{x},0) \neq \rho(\boldsymbol{x},t)$, the acceleration $\boldsymbol{a}$ must change in time $t$ and likewise, it could also change in $\boldsymbol{x}$, so that $\boldsymbol{a}(\boldsymbol{x}, t) \neq \text{const.}$
3. Then, in `momentbasedmethod.py`, line 397, `lbmpy` directly uses $\boldsymbol{F}$ as specified by the user. Here, the change in $\boldsymbol{a}(\boldsymbol{x}, t)$ is not taken into account.
How it should be implemented: When using a compressible equilibrium with a force model, the user should be allowed to either specify
- a whole force density field, where the force density may change, so that $\boldsymbol{F}(\boldsymbol{x},t)$
- the acceleration $\boldsymbol{a} = \text{const.}$ rather than a force density $\boldsymbol{F}$. This acceleration can be directly used in the computation of the macroscopic velocity, without needing to take the density into account. Finally, in the LBM collision, `lbmpy` should use the force density $\rho(\boldsymbol{x},t) \boldsymbol{a}$.
To illustrate the problem, I have reprinted the relevant equations from the book of T. Krüger, p. 233:
$\boldsymbol{u}(\boldsymbol{x},t) = 1/\rho(\boldsymbol{x},t) \sum_{i}f_{i}(\boldsymbol{x},t) + \boldsymbol{F} \Delta t / 2 / \rho(\boldsymbol{x},t)$, where I assumed that a user specifies a constant force density $\boldsymbol{F}$ for the whole domain.
$\boldsymbol{S_{i}}(\boldsymbol{x},t) \sim \boldsymbol{F}$, where $\boldsymbol{S_{i}}$ is a source term added to the collision operator. Note that the index $i$ should not be bold, but the LaTeX interpreter here does not allow to write it correctly.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/38Inplace change of lbm config2022-11-12T09:35:10+01:00Markus HolzerInplace change of lbm configSome functions try to change the provided config dataclasses internally. An example can be seen here:
https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/creationfunctions.py#L768
This does not work and the `lbm_config` does no...Some functions try to change the provided config dataclasses internally. An example can be seen here:
https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/lbmpy/creationfunctions.py#L768
This does not work and the `lbm_config` does not hold `lb_method` after calling itMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/34Update Entropic and Fluctuating LB Methods2022-04-06T14:22:52+02:00Frederik HennigUpdate Entropic and Fluctuating LB MethodsWith MR !113 complete, lbmpy's derivation framework is now mostly built around deriving relaxation equations in moment space. However, the entropic and fluctuating methods available in lbmpy are not yet integrated into this new derivatio...With MR !113 complete, lbmpy's derivation framework is now mostly built around deriving relaxation equations in moment space. However, the entropic and fluctuating methods available in lbmpy are not yet integrated into this new derivation framework. The advantages of zero-centered storage (which leads to higher numerical accuracy), FLOP reduction by the improved transformation equations, etc. are hence not available to them.
Both the entropic LBMs and the fluctuation modification should hence be integrated with this framework. Doing this in an optimal way requires intricate knowledge about these methods and should hence be done by someone who understands their principles well enough.
Especially the fluctuation extension seems to be well fit for implementation using a specialized equilibrium class (or so I think; I don't really know anything about fluctuating LB, that's why I haven't tried my hand on it).https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/32Wrong number of relaxation rates error message2022-03-21T16:15:53+01:00Daniel BauerWrong number of relaxation rates error messageWhen specifying the wrong number of relaxation rates, the error message should contain the exact number (numeric value) of rates to specify.
At least for the cumulant methods this is not the case.When specifying the wrong number of relaxation rates, the error message should contain the exact number (numeric value) of rates to specify.
At least for the cumulant methods this is not the case.https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/31Update Full Scenarios2022-03-10T09:05:43+01:00Markus HolzerUpdate Full ScenariosThe Full scenario test cases in lbmpy are mostly outdated and should be reworkedThe Full scenario test cases in lbmpy are mostly outdated and should be reworkedMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/29Relaxation Rate Grouping2022-02-09T13:39:21+01:00Markus HolzerRelaxation Rate GroupingAs shown in the literature it is not a particularly good idea to define the relaxation rate of the moments by the ordering. In fact, there are different things that need to be considered. The most prominent one is the isotropy condition....As shown in the literature it is not a particularly good idea to define the relaxation rate of the moments by the ordering. In fact, there are different things that need to be considered. The most prominent one is the isotropy condition. This means that moments that are rotated forms of others should be relaxed with the same relaxation rate. The idea is defined [here](https://www.sciencedirect.com/science/article/pii/S0898122115002126).
Furthermore, the big problem with MRT-like methods is that moments are not statistically independent. Thus moments sharing information with each other should not be relaxed with different relaxation rates. This could lead to another approach when thinking about the grouping of the relaxation rates.Jonas PlewinskiJonas Plewinskihttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/19Update Benchmark code2021-10-28T09:06:06+02:00Markus HolzerUpdate Benchmark codeIn `lbmpy_test` benchmark code can be found to benchmark most configurations `lbmpy` is capable of. However, this is outdated and needs an updateIn `lbmpy_test` benchmark code can be found to benchmark most configurations `lbmpy` is capable of. However, this is outdated and needs an updatehttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/24Demystify the parameters of LBMConfig2021-10-24T10:56:57+02:00Markus HolzerDemystify the parameters of LBMConfigLBMConfig defines all parameters which are used to derive the LBM collision operator. However, for new users (and even for long time users) it is often very hard to tell which parameters even make sense in certain situations.
There are...LBMConfig defines all parameters which are used to derive the LBM collision operator. However, for new users (and even for long time users) it is often very hard to tell which parameters even make sense in certain situations.
There are some parameters that always make sense. For example the `streaming_pattern` or the `field_name`. No matter what operator is derived every streaming pattern can be applied and the name of the field is obviously independent of all other definitions.
On the other side, there are parameters that are very specific to specific methods. For example `galilean_correction` only belongs to D3Q27 cumlumat methods. Or `weighted` only belongs to orthogonal MRT methods. When a user defines combinations that do not work together two situations appear.
The first and maybe most dangerous situation is that the parameter is just ignored. For example if `Method.SRT` is used as the method and `weighted` would be set to `True` it is just ignored that a user wanted to weight something here. While in this case, it might be obvious (at least for somewhat experienced users) it is still dangerous. There are more combinations that are not so obvious. For example when `compressible` is set to `False` and cumulants are derived it is just ignored, because our cumulants are only defined for compressible LB methods or that `equilibrium_order` < 4 has no effect for cumulant methods because they are defined to be at least fourth-order accurate in the equilibrium. In this situation, one really needs to know the theory quite well to understand why the combination makes no sense. Even for advanced users, this might end up as a pitfall.
The second situation is that combinations produce errors because they do not make sense or because our derivation is not general enough. An example would be defining a fluctuating LB method for an SRT scheme. This produces `Fluctuations can only be added to weighted-orthogonal methods`. While a user has quite a good explanation of what happens here it is still a bit frustrating that such combinations are not explained at least in some documentation.
But also not all combinations produce such nice error messages. Most others just fail due to some mysterious error caused by SymPy when the derivation starts.https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/21PDF Initialisation2021-09-28T15:34:21+02:00Markus HolzerPDF InitialisationAs described in section 5.5.2.1 in the book by Krüger et al. it is often important to also treat the non-equilibrium correctly when initializing the PDFs. This is not done in lbmpy so far and should be added.As described in section 5.5.2.1 in the book by Krüger et al. it is often important to also treat the non-equilibrium correctly when initializing the PDFs. This is not done in lbmpy so far and should be added.https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/20Speed of sound in LB method2021-08-12T18:08:45+02:00Markus HolzerSpeed of sound in LB methodThe speed of sound cs is used to generate the equilibra for the LB methods, but the method itself does not know the speed of sound. Thus, in functions using the LB method it is not possible to extract the speed of sound again. This is fo...The speed of sound cs is used to generate the equilibra for the LB methods, but the method itself does not know the speed of sound. Thus, in functions using the LB method it is not possible to extract the speed of sound again. This is for example the case in force models.
All LB methods should be aware of the speed of sound and should hold it as a property.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/16Cumulant test case2021-02-08T20:38:55+01:00Michael Kuronmkuron@icp.uni-stuttgart.deCumulant test caseThe cumulant test case had to be reduced in !61 so it runs faster. Unfortunately, it doesn't test long-term stability or physics anymore. Please extend to a proper test case.The cumulant test case had to be reduced in !61 so it runs faster. Unfortunately, it doesn't test long-term stability or physics anymore. Please extend to a proper test case.Markus HolzerMarkus Holzer