lbmpy issueshttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues2019-08-12T16:53:58+02:00https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/2Fluctuating (Randomized, Thermalized) LBM2019-08-12T16:53:58+02:00Martin BauerFluctuating (Randomized, Thermalized) LBM- [ ] get random number from external field, add kernel to test suite @winterhalter
- [ ] physical test case to check random number correlation (auto correlation function?) @kuron
- [x] final version should compute random numbers in th...- [ ] get random number from external field, add kernel to test suite @winterhalter
- [ ] physical test case to check random number correlation (auto correlation function?) @kuron
- [x] final version should compute random numbers in the kernel itself. 'mulhi' / 'mullo' functions are required
- philox RNG
- write a pystencils function similar to bitoperations for these operations
- on x86 there are intrinsics for mulhi/mullo, alternatively one could also use AES instead of philox since there is also a intrinsic for that
- on GPU there should also be an intrinsic
- C fallback as one-liner
- two versions required for drawing float & double random numbers
- fast versions produce 2 or more RN per step, how to handle this?
Fixes https://i10git.cs.fau.de/walberla/walberla/issues/80Martin BauerMartin Bauerhttps://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/3Implementation of FreeSlip Boundaries2021-07-09T10:14:41+02:00Markus HolzerImplementation of FreeSlip BoundariesFreeSlip Boundaries as in waLBerla should be added
Link to the waLBerla implementation:
[waLBerla FreeSlip](https://i10git.cs.fau.de/walberla/walberla/blob/master/src/lbm/boundary/FreeSlip.h)FreeSlip Boundaries as in waLBerla should be added
Link to the waLBerla implementation:
[waLBerla FreeSlip](https://i10git.cs.fau.de/walberla/walberla/blob/master/src/lbm/boundary/FreeSlip.h)https://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/5create_mrt_orthogonal's definition of orthogonality is inconsistent2019-11-28T20:34:47+01:00Michael Kuronmkuron@icp.uni-stuttgart.decreate_mrt_orthogonal's definition of orthogonality is inconsistentOrthogonality can either be unweighted (as in a scalar product) or weighted (as in a weighted scalar product). `lbmpy.methods.creationfunctions.create_mrt_orthogonal` mixes the two. The D2Q9 is unweighted-orthogonal, the D3Q19 is weighte...Orthogonality can either be unweighted (as in a scalar product) or weighted (as in a weighted scalar product). `lbmpy.methods.creationfunctions.create_mrt_orthogonal` mixes the two. The D2Q9 is unweighted-orthogonal, the D3Q19 is weighted-orthogonal, and the D3Q27 is unweighted-orthogonal. ~~The D3Q15 is almost weighted-orthogonal, but contains a minor error somewhere that leads to two off-diagonal elements when checking for weighted-orthogonality~~(solved by !15).
The Krüger book (and the original d'Humieres et al. paper) give the moments for an unweighted-orthogonal D3Q15 and D3Q19 and I don't know where the weighted D3Q15 version in the code came from. The weighted D3Q19 clearly comes from Schiller/Dünweg/Ladd.
The D2Q9 can be made weighted-orthogonal by this simple change:
```diff
--- a/lbmpy/methods/creationfunctions.py
+++ b/lbmpy/methods/creationfunctions.py
@@ -10,7 +10,7 @@ from lbmpy.maxwellian_equilibrium import (
compressible_to_incompressible_moment_value, get_cumulants_of_continuous_maxwellian_equilibrium,
get_cumulants_of_discrete_maxwellian_equilibrium,
get_moments_of_continuous_maxwellian_equilibrium,
- get_moments_of_discrete_maxwellian_equilibrium)
+ get_moments_of_discrete_maxwellian_equilibrium, get_weights)
from lbmpy.methods.abstractlbmethod import RelaxationInfo
from lbmpy.methods.conservedquantitycomputation import DensityVelocityComputation
from lbmpy.methods.cumulantbased import CumulantBasedLbMethod
@@ -388,9 +388,10 @@ def create_mrt_orthogonal(stencil, relaxation_rate_getter=None, maxwellian_momen
moment_to_relaxation_rate_dict = OrderedDict()
if have_same_entries(stencil, get_stencil("D2Q9")):
moments = get_default_moment_set_for_stencil(stencil)
- orthogonal_moments = gram_schmidt(moments, stencil)
+ weights = get_weights(stencil, sp.Rational(1,3))
+ orthogonal_moments = gram_schmidt(moments, stencil, weights)
orthogonal_moments_scaled = [e * common_denominator(e) for e in orthogonal_moments]
nested_moments = list(sort_moments_into_groups_of_same_order(orthogonal_moments_scaled).values())
elif have_same_entries(stencil, get_stencil("D3Q15")):
sq = x ** 2 + y ** 2 + z ** 2
nested_moments = [
```
It can also be made to match the version from the Schiller/Dünweg/Ladd paper, which chooses slightly different moments, by this change:
```diff
--- a/lbmpy/methods/creationfunctions.py
+++ b/lbmpy/methods/creationfunctions.py
@@ -10,7 +10,7 @@ from lbmpy.maxwellian_equilibrium import (
compressible_to_incompressible_moment_value, get_cumulants_of_continuous_maxwellian_equilibrium,
get_cumulants_of_discrete_maxwellian_equilibrium,
get_moments_of_continuous_maxwellian_equilibrium,
- get_moments_of_discrete_maxwellian_equilibrium)
+ get_moments_of_discrete_maxwellian_equilibrium, get_weights)
from lbmpy.methods.abstractlbmethod import RelaxationInfo
from lbmpy.methods.conservedquantitycomputation import DensityVelocityComputation
from lbmpy.methods.cumulantbased import CumulantBasedLbMethod
@@ -388,9 +388,16 @@ def create_mrt_orthogonal(stencil, relaxation_rate_getter=None, maxwellian_momen
moment_to_relaxation_rate_dict = OrderedDict()
if have_same_entries(stencil, get_stencil("D2Q9")):
moments = get_default_moment_set_for_stencil(stencil)
- orthogonal_moments = gram_schmidt(moments, stencil)
+ weights = get_weights(stencil, sp.Rational(1,3))
+ orthogonal_moments = gram_schmidt(moments, stencil, weights)
orthogonal_moments_scaled = [e * common_denominator(e) for e in orthogonal_moments]
nested_moments = list(sort_moments_into_groups_of_same_order(orthogonal_moments_scaled).values())
+ sq = x ** 2 + y ** 2
+ nested_moments[2][0] = 3 * sq - 2
+ nested_moments[2][1] = 2 * x ** 2 - sq
+ nested_moments[3][0] = (3 * sq - 4) * x
+ nested_moments[3][1] = (3 * sq - 4) * y
+ nested_moments[4][0] = 9 * sq ** 2 - 15 * sq + 2
elif have_same_entries(stencil, get_stencil("D3Q15")):
sq = x ** 2 + y ** 2 + z ** 2
nested_moments = [
```
----------------
How to check for unweighted orthogonality:
```python
m = create_mrt_orthogonal(get_stencil("D3Q27"), maxwellian_moments=True)
assert (m.moment_matrix * m.moment_matrix.T).is_diagonal()
```
How to check for weighted orthogonality:
```python
m = create_mrt_orthogonal(get_stencil("D3Q19"), maxwellian_moments=True)
w = get_weights(m.stencil, sp.Rational(1,3))
assert (sp.matrix_multiply_elementwise(m.moment_matrix, sp.Matrix([w]*19)) * m.moment_matrix.T).is_diagonal()
```
-----------------
The test case test_mrt_orthogonal in test_momentbased_methods_equilibrium.py currently only checks the two unweighted-orthogonal ones.
------------------
To resolve the inconsistency, all variants should be automatically constructed via Gram-Schmidt. An optional argument should be provided that allows the choice of weighted vs. unweighted. Also, some tricks may be necessary during orthogonalization to get those specific moments that certain people in literature use; these should also be selectable via an optional argument.Michael Kuronmkuron@icp.uni-stuttgart.deMichael Kuronmkuron@icp.uni-stuttgart.dehttps://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/7Lees-Edwards LB2021-01-22T16:47:22+01:00Michael Kuronmkuron@icp.uni-stuttgart.deLees-Edwards LBWill be implemented by @Bindgen according to https://doi.org/10.1023/A:1014595628808. It requires a modified equilibrium distribution and a communication scheme that interpolates populations across the periodic boundary.Will be implemented by @Bindgen according to https://doi.org/10.1023/A:1014595628808. It requires a modified equilibrium distribution and a communication scheme that interpolates populations across the periodic boundary.Sebastian Bindgen Sebastian Bindgen https://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/9Boundaries don't work with OpenCL2020-03-12T20:21:59+01:00Michael Kuronmkuron@icp.uni-stuttgart.deBoundaries don't work with OpenCLBoundary conditions work fine on CPU and CUDA, but they don't have any effect on OpenCL. Here is a Poiseuille flow test case that shows that, just change the target in the third block. [gpu_boundary.ipynb](/uploads/88e7dc4e1c9201013e831c...Boundary conditions work fine on CPU and CUDA, but they don't have any effect on OpenCL. Here is a Poiseuille flow test case that shows that, just change the target in the third block. [gpu_boundary.ipynb](/uploads/88e7dc4e1c9201013e831c6f15de5832/gpu_boundary.ipynb)https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/10KBC LBMs do not work with the current MRT description2020-06-15T20:59:48+02:00Markus HolzerKBC LBMs do not work with the current MRT descriptionConserved quantities are relaxed with zero. If a KBC is created it looks at the number of relaxation rates which has to be 2. Since the conserved quantities are already fixed with 0 it causes problems.
Possible fix would be to state th...Conserved quantities are relaxed with zero. If a KBC is created it looks at the number of relaxation rates which has to be 2. Since the conserved quantities are already fixed with 0 it causes problems.
Possible fix would be to state the relaxation time of the conserved quantities as a parameter for the create functions.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/11Guo and Buick force is wrong when applied to non-SRT LBs2020-09-16T22:34:25+02:00Michael Kuronmkuron@icp.uni-stuttgart.deGuo and Buick force is wrong when applied to non-SRT LBsAs a simple test, we apply a constant force to a fluid and measure the resulting total momentum. It should be force * number of cells * number of time steps. We do this for different relaxation and force models.
```python
from pystencil...As a simple test, we apply a constant force to a fluid and measure the resulting total momentum. It should be force * number of cells * number of time steps. We do this for different relaxation and force models.
```python
from pystencils.session import *
from lbmpy.session import *
import lbmpy
from lbmpy.macroscopic_value_kernels import macroscopic_values_setter
L = (40, 40)
stencil = get_stencil("D2Q9")
eta = 0.15
omega = lbmpy.relaxationrates.relaxation_rate_from_lattice_viscosity(eta)
F = [2e-4, -3e-4]
dh = ps.create_data_handling(L, periodicity=True, default_target='cpu')
src = dh.add_array('src', values_per_cell=len(stencil))
dst = dh.add_array_like('dst', 'src')
ρ = dh.add_array('rho')
u = dh.add_array('u', values_per_cell=dh.dim)
collision = create_lb_update_rule(method="trt",
stencil=stencil,
relaxation_rate=omega,
compressible=True,
force_model='guo',
force=F,
kernel_type='collide_only',
optimization={'symbolic_field': src})
stream = create_stream_pull_with_output_kernel(collision.method, src, dst,
{'density': ρ, 'velocity': u})
opts = {'cpu_openmp': True,
'cpu_vectorize_info': None,
'target': dh.default_target}
stream_kernel = ps.create_kernel(stream, **opts).compile()
collision_kernel = ps.create_kernel(collision, **opts).compile()
def init():
dh.fill(ρ.name, 1)
dh.fill(u.name, 0)
setter = macroscopic_values_setter(collision.method, velocity=(0,)*dh.dim,
pdfs=src.center_vector, density=ρ.center)
kernel = ps.create_kernel(setter, ghost_layers=0).compile()
dh.run_kernel(kernel)
sync_pdfs = dh.synchronization_function([src.name]) # needed before stream, but after collision
def time_loop(steps):
dh.all_to_gpu()
for i in range(steps):
dh.run_kernel(collision_kernel)
sync_pdfs()
dh.run_kernel(stream_kernel)
dh.swap(src.name, dst.name)
dh.all_to_cpu()
t = 100
init()
time_loop(t)
total = np.sum(dh.gather_array(u.name), axis=(0,1))
print(total/np.prod(L)/F/t)
```
We see that for SRT or Luo, the script always prints 1.0, so all force applied has been converted into momentum. For TRT with Guo, it produces an omega-dependent number, which means that force has not been applied correctly.
| Method | Momentum per Force |
| ------ | ------------------ |
| SRT Guo | 1.0 |
| SRT Luo | 1.0 |
| SRT Buick | 1.0 |
| TRT Guo | * |
| TRT Luo | 1.0 |
| TRT Buick | * |
| omega | * |
| ----- | ----- |
| 2 | 0 |
| 1.8 | 0.22903226 |
| 1.5 | 0.55769231 |
| 1.2 | 0.87058824 |
| 1 | 1.07142857 |
| 0.8 | 1.26666667 |
| 0.5 | 1.55 |
| 0.25 | 1.77822581 |
| 0.1 | 1.92 |
| 0 | 2 |Michael Kuronmkuron@icp.uni-stuttgart.deMichael Kuronmkuron@icp.uni-stuttgart.dehttps://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/12Apply force in moment space2020-11-17T19:31:43+01:00Michael Kuronmkuron@icp.uni-stuttgart.deApply force in moment spaceAs discussed with @bauer and @holzer, we should try applying the force in moment space. This should be equivalent to the Guo force model, but save significant FLOPs.
To support this effort, the automatic Chapman-Enskog analysis should b...As discussed with @bauer and @holzer, we should try applying the force in moment space. This should be equivalent to the Guo force model, but save significant FLOPs.
To support this effort, the automatic Chapman-Enskog analysis should be extended to support forces.https://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/15Bug in Vectorization with GCC < 8.1.0 and Intel C++ Compiler2022-03-31T19:46:23+02:00Markus HolzerBug in Vectorization with GCC < 8.1.0 and Intel C++ CompilerWhen compiled with `-Ofast -march=native` (default in lbmpy and pystencils), the following channel flow test case is subject to numerical instabilities in the PDF field.
This was observed with various GCC compiler versions below GCC 8.1....When compiled with `-Ofast -march=native` (default in lbmpy and pystencils), the following channel flow test case is subject to numerical instabilities in the PDF field.
This was observed with various GCC compiler versions below GCC 8.1.0 and with the Intel C++ compiler versions 17 to 19 (20 was not tested). It could not be observed with the LLVM compiler versions 7 to 10.
The bug is supposedly present in any version of lbmpy and pystencils, as it can be reproduced with lbmpy and pystencils versions 0.2.9, 0.2.13 and 0.2.14.
The minimal required compile flags to get the instabilities on GCC are `-O3 -fno-signed-zeros -fno-trapping-math -fassociative-math -mavx`.
The GCC commit that fixed this issue was identified to be [7c080ad](https://github.com/gcc-mirror/gcc/commit/7c080ade9d8198958a1a37854d5cc56f7b76b9f4). There, the cost estimation for vectorization changes, such that the auto-vectorization behavior differs. We tried `-fvect-cost-model=unlimited` to force vectorization irrespective of costs, but that did not make a difference. **Since we do not know which commit fixes the actual bug, it is possible that it is present in gcc 8 or even the current gcc 10** -- only the specific code sample below no longer runs into it because it does not get auto-vectorized anymore.
```
from lbmpy.session import *
from lbmpy.moments import *
ch = create_channel(domain_size=(300, 100), force=5e-5, initial_velocity=(0.5, 0),
relaxation_rate=1.8)
ch.run(6900)
print(ch.velocity[0.5, :, 0])
```
While the flow field initially seems to be stable, it becomes unstable between time steps 6800 and 6900 and ends up with NaNs.Markus HolzerMarkus Holzerhttps://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/22lbmpy 0.4.0 not working with pystenicls 0.3.42021-09-30T13:44:21+02:00Dominik Thoennesdominik.thoennes@fau.delbmpy 0.4.0 not working with pystenicls 0.3.4I am getting
````
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/thoennes/.local/lib/python3.8/site-packages/lbmpy/__init__.py", line 1, in <module>
from .creationfunctions import create_lb_a...I am getting
````
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/thoennes/.local/lib/python3.8/site-packages/lbmpy/__init__.py", line 1, in <module>
from .creationfunctions import create_lb_ast, create_lb_collision_rule, create_lb_function,\
File "/home/thoennes/.local/lib/python3.8/site-packages/lbmpy/creationfunctions.py", line 225, in <module>
from lbmpy.simplificationfactory import create_simplification_strategy
File "/home/thoennes/.local/lib/python3.8/site-packages/lbmpy/simplificationfactory.py", line 9, in <module>
from pystencils.simp import (
ImportError: cannot import name 'insert_aliases' from 'pystencils.simp' (/home/thoennes/.local/lib/python3.8/site-packages/pystencils/simp/__init__.py)
````
when using `lbmpy` 0.4.0 and `pystenicls` 0.3.4. After updating to `pystenicls` 0.4.0 everything works again.
I guess `lbmpy` 0.4.0 needs to have `pystencils` 0.4.0 as a dependency and not just any `pystencils`.
Currently, the setup.py just says `pystencils`https://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/25Minimal SymPy succeeded although errors are thrown2023-04-05T16:28:55+02:00Markus HolzerMinimal SymPy succeeded although errors are thrownMarkus 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/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 Holzer