lbmpy issueshttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues2022-05-12T13:22:51+02:00https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/35Fix Quicktests2022-05-12T13:22:51+02:00Markus HolzerFix QuicktestsOne of the quicktests is commented out for the windows pipeline due to very strange instabilities that can not be reproduced outside the pipeline:
https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/conftest.py#L65
It would be good t...One of the quicktests is commented out for the windows pipeline due to very strange instabilities that can not be reproduced outside the pipeline:
https://i10git.cs.fau.de/pycodegen/lbmpy/-/blob/master/conftest.py#L65
It would be good to find out what happens here. Also, the quicktests make no sense so they should be reworked.Markus 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/33Unphysical behavior in simulations2022-03-31T19:14:30+02:00Markus HolzerUnphysical behavior in simulationsIn some simulations setups, an unphysical stripe pattern has been noticed. As an example, a force-driven channel can be used as attached to the Issue.
At this point, several sources could cause the problems:
1. Numerical round off erro...In some simulations setups, an unphysical stripe pattern has been noticed. As an example, a force-driven channel can be used as attached to the Issue.
At this point, several sources could cause the problems:
1. Numerical round off errors (see MR !113)
2. Incorrect/Non-ideal initialization of the domain
3. Non-ideal relaxation rates (especially the influence of the bulk relaxation rate should be looked at, however also SRT simulations are affected)
This issue here should function as documentation of the problems in different configurations
[SimpleChannelFlow.ipynb](/uploads/dde0360f182ee20e1c7bb656849a1d9c/SimpleChannelFlow.ipynb)Markus HolzerMarkus Holzerhttps://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/30Inconsistent normal directions in boundary conditions2022-03-04T11:21:22+01: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/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/28More precision problems2021-12-21T21:35:33+01: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/26Sometimes the latest python pipeline failes2021-10-26T17:26:18+02:00Markus HolzerSometimes the latest python pipeline failesThe behaviour can be seen in this example:
https://i10git.cs.fau.de/holzer/lbmpy/-/jobs/660425The behaviour can be seen in this example:
https://i10git.cs.fau.de/holzer/lbmpy/-/jobs/660425Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/25Minimal SymPy succeeded although errors are thrown2021-10-26T11:09:23+02:00Markus HolzerMinimal SymPy succeeded although errors are thrownMarkus HolzerMarkus Holzerhttps://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/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/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