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/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/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/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/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/36Codegen for lattice Boltzmann methods on unstructured grids2022-11-14T12:56:20+01:00Ivan PribecCodegen for lattice Boltzmann methods on unstructured gridsLBM can also be used with other discretization methods (e.g. FVM, or FEM) for the streaming step. The PDFs are now associated with the nodes of a triangular or quadrilateral mesh. Since the streaming step is now irregular and involves fl...LBM can also be used with other discretization methods (e.g. FVM, or FEM) for the streaming step. The PDFs are now associated with the nodes of a triangular or quadrilateral mesh. Since the streaming step is now irregular and involves floating point calculation, for the update rule it is common to use two separate arrays. Nevertheless, I could still use lbmpy for the collision part by setting `kernel_type='collide_only'` in the `LBMConfig`.
Inspecting the prototype and code of generated kernels, e.g.
```c
FUNC_PREFIX void mylbmkernel(double * RESTRICT _data_src,
int64_t const _size_src_0, int64_t const _size_src_1,
int64_t const _stride_src_0, int64_t const _stride_src_1, int64_t const _stride_src_2,
double omega)
```
I have inferred that lbmpy assumes the PDFs are stored in a 3-dimensional (padded) array (in 2D), with either the `xyzf` or `fxyz` storage layout. In Fortran notation, assuming `fxyz` (SoA) storage this would be something like:
```fortran
! In Fortran, the order is opposite from C
real(c_double), allocatable :: fcache(:,:,:,:)
! y,x,f,isrc/idst
```
For the unstructured method (FVM, FEM), however I will just use a "linear" array:
```fortran
real(c_double), allocatable :: fcache( :,:,:)
! xy,f,isrc/idst
```
If I'm not mistaken, this would correspond to setting `__size_src_1 = 1, __stride_src_1 = 0` to essentially "flatten" one dimension of the array.
Would it be possible for lbmpy to provide an option for applying the collision rule over a flat/one-dimensional index space? Does it make sense to do it in blocks with smaller buffers for density and velocity?https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/35Fix Quicktests2023-06-07T10:59:34+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 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/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 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/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 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/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/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/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/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/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 Holzer