lbmpy issueshttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues2024-01-16T16:17:43+01:00https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/41Modernize lbmpy's development environment2024-01-16T16:17:43+01:00Frederik HennigModernize lbmpy's development environmentBasically the same as pycodegen/pystencils#75.Basically the same as pycodegen/pystencils#75.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/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/1Relace `update_with_default_parameters`2021-09-21T12:35:16+02:00Stephan SeitzRelace `update_with_default_parameters`LBM methods and kernels can be constructed in a fabricator pattern with a lot of magic parameters bundled as dict. Users need to read the documentation or the source code to know about all the option. Some lazy users are to lazy to read....LBM methods and kernels can be constructed in a fabricator pattern with a lot of magic parameters bundled as dict. Users need to read the documentation or the source code to know about all the option. Some lazy users are to lazy to read.
Wouldn't it be better to provide a dict-like type for that with a `__init__` that replaces `update_with_default_parameters` to provide the user with autocomplete and documentation (member-wise) about which fixed members this `dict` has? The type could still duck type or subclass a dict and would be explicitly convertible via `dict(vars(type))`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/18Segmentation fault for large geometries2021-06-07T15:30:42+02:00Arttu MiettinenSegmentation fault for large geometriesThe previous issue report on segfault related to int32-based indexing of arrays seems to have disappeared, so I'll make a new one. If the disappearance was caused by me not responding, I apologize, but I'm working with this stuff only ev...The previous issue report on segfault related to int32-based indexing of arrays seems to have disappeared, so I'll make a new one. If the disappearance was caused by me not responding, I apologize, but I'm working with this stuff only every other week.
In short, the issue was segmentation fault in code like this:
```
r = 450
domain_size = (r, r, r)
ldc = create_lid_driven_cavity(domain_size=domain_size, method='srt', relaxation_rate=1.6,
optimization={'openmp': False,
'double_precision': True,
'vectorization': False})
ldc.run(2)
```
The solution suggested in the previous report by some staff member did not work out of the box. Instead, the attached patches seem to fix the issue by changing variables related to array indexing in indexed CPU kernels from int32 to int64. [I don't have rights to post a merge request, hence patches] There is one patch file for pystencils and another for lbmpy.
The changes don't seem to affect results of any test cases.
[pystencils-int32-index-fix.patch](/uploads/e4927a4c3fbca6a7bbe8fb2000c9a0d4/pystencils-int32-index-fix.patch)
[lbmpy-int32-index-fix.patch](/uploads/b8511dd7df28c87bdd477f8af8f5ecdf/lbmpy-int32-index-fix.patch)https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/37Simplify Setter Assignements2022-11-08T09:04:21+01:00Markus HolzerSimplify Setter AssignementsSetter Assignments might be huge. They need their own simplifications as the collision.Setter Assignments might be huge. They need their own simplifications as the collision.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/26Sometimes the latest python pipeline failes2024-01-16T14:53:24+01: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/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/8test_phasefieldstep_direct fails after upgrade of scikit-image from 0.15.0 to...2019-12-04T11:15:01+01:00Michael Kuronmkuron@icp.uni-stuttgart.detest_phasefieldstep_direct fails after upgrade of scikit-image from 0.15.0 to 0.16.1The *pycodegen-integration* job in pystencils now reports a failing test_phasefieldstep_direct (https://i10git.cs.fau.de/pycodegen/pystencils/-/jobs/327659). After a local test, I can confirm that this happens with scikit-image 0.16.1 an...The *pycodegen-integration* job in pystencils now reports a failing test_phasefieldstep_direct (https://i10git.cs.fau.de/pycodegen/pystencils/-/jobs/327659). After a local test, I can confirm that this happens with scikit-image 0.16.1 and did not happen with scikit-image 0.15.0.Martin BauerMartin Bauerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/4Tests for fluctuating MRT LB2019-11-21T18:02:15+01:00Michael Kuronmkuron@icp.uni-stuttgart.deTests for fluctuating MRT LBRudolfWeeberRudolfWeeberhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/6The fluctuating feature should throw if the basis vectors of the underlying L...2019-11-27T16:47:43+01:00RudolfWeeberThe fluctuating feature should throw if the basis vectors of the underlying LB aren't orthogonalMichael Kuronmkuron@icp.uni-stuttgart.deMichael Kuronmkuron@icp.uni-stuttgart.dehttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/27Too long test cases2021-11-16T09:11:05+01:00Markus HolzerToo long test casesThe long-run pipeline gives the following output:
```
13475.37s call lbmpy_tests/test_conserved_quantity_relaxation_invariance.py::test_srt
1078.84s call lbmpy_tests/test_diffusion.py::test_diffusion
505.76s call lbmpy_tests...The long-run pipeline gives the following output:
```
13475.37s call lbmpy_tests/test_conserved_quantity_relaxation_invariance.py::test_srt
1078.84s call lbmpy_tests/test_diffusion.py::test_diffusion
505.76s call lbmpy_tests/centeredcumulant/test_flow_around_sphere.py::test_flow_around_sphere_long[True-Stencil.D3Q27]
460.70s call lbmpy_tests/centeredcumulant/test_flow_around_sphere.py::test_flow_around_sphere_long[False-Stencil.D3Q27]
243.29s call lbmpy_tests/centeredcumulant/test_flow_around_sphere.py::test_flow_around_sphere_long[False-Stencil.D3Q19]
218.93s call lbmpy_tests/centeredcumulant/test_flow_around_sphere.py::test_flow_around_sphere_short[False-Stencil.D3Q27]
214.62s call lbmpy_tests/centeredcumulant/test_flow_around_sphere.py::test_flow_around_sphere_short[True-Stencil.D3Q27]
178.90s call lbmpy_tests/phasefield/test_n_phase_boyer_analytical.ipynb::lbmpy_tests/phasefield/test_n_phase_boyer_analytical.ipynb
174.18s call lbmpy_tests/test_central_moment.py::test_central_moment_ldc
172.26s call lbmpy_tests/test_float_kernel.py::test_scenario[Method.CENTRAL_MOMENT-True]
167.89s call lbmpy_tests/test_float_kernel.py::test_scenario[Method.CENTRAL_MOMENT-False]
152.72s call lbmpy_tests/test_force.py::test_modes_central_moment_longrun[False-ForceModel.SIMPLE-Stencil.D3Q27]
148.64s call lbmpy_tests/test_force.py::test_modes_central_moment_longrun[False-ForceModel.KUPERSHTOKH-Stencil.D3Q27]
133.62s call lbmpy_tests/centeredcumulant/test_equilibrium.py::test_equilibrium_pdfs[PdfsToCentralMomentsByMatrix-Stencil.D3Q27]
133.46s call lbmpy_tests/test_float_kernel.py::test_scenario[Method.CUMULANT-False]
129.22s call lbmpy_tests/test_float_kernel.py::test_scenario[Method.CUMULANT-True]
122.35s call lbmpy_tests/test_central_moment_transform.py::test_backward_transform[Stencil.D3Q27-polynomial]
121.65s call lbmpy_tests/test_force.py::test_modes_central_moment_longrun[False-ForceModel.GUO-Stencil.D3Q27]
120.27s call lbmpy_tests/test_force.py::test_modes_central_moment_longrun[False-ForceModel.SHANCHEN-Stencil.D3Q27]
119.87s call lbmpy_tests/centeredcumulant/test_equilibrium.py::test_equilibrium_pdfs[FastCentralMomentTransform-Stencil.D3Q27]
```
Especially, the first two test cases should be shortenedMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/33Unphysical behavior in simulations2023-05-12T11:49:52+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/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/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/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/23Vectorization is not working2021-10-31T14:08:53+01:00Christoph SchwarzmeierVectorization is not workingThe `LbCodeGenerationExample`-Test in waLBerla could not be built with the following settings in CMake:
```
-DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++
-DWALBERLA_OPTIMIZE_FOR_LOCALHOST=ON
-DWALBERLA_BUILD_WITH_OPENMP=ON
-DWALB...The `LbCodeGenerationExample`-Test in waLBerla could not be built with the following settings in CMake:
```
-DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++
-DWALBERLA_OPTIMIZE_FOR_LOCALHOST=ON
-DWALBERLA_BUILD_WITH_OPENMP=ON
-DWALBERLA_BUILD_WITH_OPENMESH=ON
-DWALBERLA_BUILD_WITH_CODEGEN=ON
-DWALBERLA_BUILD_SHOWCASES=ON
-DWALBERLA_BUILD_TESTS=ON
-DPYTHON_EXECUTABLE=/local/ca36xymo/miniconda3/bin/python3.9
-DWALBERLA_DOUBLE_ACCURACY=OFF
```
Instead, the code generation results in the following error:
```
$ make LbCodeGenerationExample
[ 0%] Generating default_codegen/LbCodeGenerationExample_LatticeModel.cpp, default_codegen/LbCodeGenerationExample_LatticeModel.h, default_codegen/LbCodeGenerationExample_NoSlip.cpp, default_codegen/LbCodeGenerationExample_NoSlip.h, default_codegen/LbCodeGenerationExample_UBB.cpp, default_codegen/LbCodeGenerationExample_UBB.h, default_codegen/LbCodeGenerationExample.h
Traceback (most recent call last):
File "/local/ca36xymo/walberla/tests/lbm/codegen/LbCodeGenerationExample.py", line 34, in <module>
generate_lattice_model(ctx, 'LbCodeGenerationExample_LatticeModel', collision_rule,
File "/local/ca36xymo/walberla/python/lbmpy_walberla/walberla_lbm_generation.py", line 162, in generate_lattice_model
stream_collide_ast = create_kernel(stream_collide_update_rule, config=config)
File "/local/ca36xymo/miniconda3/lib/python3.9/site-packages/pystencils/kernelcreation.py", line 142, in create_kernel
return create_domain_kernel(assignments, config=config)
File "/local/ca36xymo/miniconda3/lib/python3.9/site-packages/pystencils/kernelcreation.py", line 202, in create_domain_kernel
vectorize(ast, **config.cpu_vectorize_info)
File "/local/ca36xymo/miniconda3/lib/python3.9/site-packages/pystencils/cpu/vectorization.py", line 120, in vectorize
raise NotImplementedError("Cannot vectorize kernels that contain accesses "
NotImplementedError: Cannot vectorize kernels that contain accesses to differently typed floating point fields
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/local/ca36xymo/walberla/tests/lbm/codegen/LbCodeGenerationExample.py", line 38, in <module>
generate_info_header(ctx, 'LbCodeGenerationExample')
File "/local/ca36xymo/walberla/python/pystencils_walberla/cmake_integration.py", line 43, in __exit__
raise ValueError(error_message)
ValueError: Generated files (OUT_FILES) specified not correctlyin cmake with 'waLBerla_generate_target_from_python'
Files only specified in CMake ['LbCodeGenerationExample.h', 'LbCodeGenerationExample_LatticeModel.h', 'LbCodeGenerationExample_UBB.h', 'LbCodeGenerationExample_NoSlip.cpp', 'LbCodeGenerationExample_UBB.cpp', 'LbCodeGenerationExample_NoSlip.h', 'LbCodeGenerationExample_LatticeModel.cpp']
make[3]: *** [tests/lbm/CMakeFiles/LbCodeGenerationExampleGenerated.dir/build.make:71: tests/lbm/default_codegen/LbCodeGenerationExample_LatticeModel.cpp] Error 1
make[2]: *** [CMakeFiles/Makefile2:7662: tests/lbm/CMakeFiles/LbCodeGenerationExampleGenerated.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:7463: tests/lbm/CMakeFiles/LbCodeGenerationExample.dir/rule] Error 2
make: *** [Makefile:498: tests/lbm/CMakeFiles/LbCodeGenerationExample.dir/rule] Error 2
```
The issue should be reproducible on any of our private `i10staff*` machines (clang 10.0.0) with lbmpy and pystencils in version 0.4.0.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/14Wrong momentum density calculation for compressible methods with forces.2021-04-30T13:22:18+02:00Helen SchottenhammlWrong momentum density calculation for compressible methods with forces.In _conservedquantitycomputation.py_ (line 210f) the calculation of the momentum density uses the _macroscopic velocity shift_
```python
mom_density_eq_coll = apply_force_model_shift('macroscopic_velocity_shift', dim, mom_density_eq_coll...In _conservedquantitycomputation.py_ (line 210f) the calculation of the momentum density uses the _macroscopic velocity shift_
```python
mom_density_eq_coll = apply_force_model_shift('macroscopic_velocity_shift', dim, mom_density_eq_coll,
self._forceModel, self._compressible)
```
which defaults to <img src="https://latex.codecogs.com/svg.latex? &space;\frac{\mathbf{F}}{2\rho}" />.
When using this momentum density to calculcate the velocity (as it is done in all generated lattice models in waLBerla), we divide by the density again, resulting in the overall velocity equation
<img src="https://latex.codecogs.com/svg.latex? &space;\mathbf{u} = \frac{1}{\rho} \sum_i f_i \mathbf{c}_i + \frac{\mathbf{F}}{2\rho^2}" />,
which is obviously wrong.
Affected are all _lbmpy_ simulations that work directly on the momentum denisty, and all _waLBerla_ simulations that use generated lattice models and calculate the velocity at some point (in particular, the VTK output will be slightly off).Helen SchottenhammlHelen Schottenhammlhttps://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.