pystencils merge requestshttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests2023-03-28T09:23:11+02:00https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/322[Fix] Matplotlib arrow rendering2023-03-28T09:23:11+02:00Markus Holzer[Fix] Matplotlib arrow renderingStarting from `matplotlib = 3.5`, pystencils' definition for 3D arrows is deprecated. Therefore, 3D stencils cannot be rendered anymore.
The exact issue is stated, e.g., here : https://github.com/matplotlib/matplotlib/issues/21688
F...Starting from `matplotlib = 3.5`, pystencils' definition for 3D arrows is deprecated. Therefore, 3D stencils cannot be rendered anymore.
The exact issue is stated, e.g., here : https://github.com/matplotlib/matplotlib/issues/21688
Fixes #67Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/321Properly detect and enable vectorization on ARM2023-06-07T09:26:30+02:00Michael Kuronmkuron@icp.uni-stuttgart.deProperly detect and enable vectorization on ARM!320 has the side effect of breaking detection of SVE vectorization support and enablement of SVE in the compiler. My patch should properly fix the underlying problem.
py-cpuinfo is supported on ARM64 and can be used to detect Neon and ...!320 has the side effect of breaking detection of SVE vectorization support and enablement of SVE in the compiler. My patch should properly fix the underlying problem.
py-cpuinfo is supported on ARM64 and can be used to detect Neon and SVE. However, there was indeed a bug here -- Neon is identified as `asimd` in /proc/cpuinfo, so we should check for `asimd` instead of `neon`.
While `-march=native` was not supported by [Clang before 15](https://github.com/llvm/llvm-project/commit/955cff803e081640e149fed0742f57ae1b84db7d), `-mcpu=native` is supported by [GCC 6+](https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/AArch64-Options.html) and [Clang 7+](https://github.com/llvm-mirror/clang/commit/86c991513001535af6b82bcb1f7c45ab60d2adf0). Let's use that instead of not adding a flag at all -- otherwise SVE support is not enabled in the compiler even if the hardware supports it.Helen SchottenhammlHelen Schottenhammlhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/320ARM for linux2023-03-27T20:07:49+02:00Helen SchottenhammlARM for linuxUntil now, ARM architectures are only allowed for Darwin systems. This MR extends their usage to Linux systems.Until now, ARM architectures are only allowed for Darwin systems. This MR extends their usage to Linux systems.Helen SchottenhammlHelen Schottenhammlhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/319Resolve "Absolute access is probably not copied correctly after _eval_subs()"2023-03-31T17:05:29+02:00Nils KohlResolve "Absolute access is probably not copied correctly after _eval_subs()"Closes #66Closes #66Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/318[Fix] GPU Buffer with iteration slices2023-03-31T09:18:50+02:00Markus Holzer[Fix] GPU Buffer with iteration slicesGPU buffers did not work in combination with iteration slices before. This is resolved hereGPU buffers did not work in combination with iteration slices before. This is resolved hereMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/317[FIX] Iteration slices with GPU kernels2023-03-17T11:26:57+01:00Markus Holzer[FIX] Iteration slices with GPU kernelsFixes #58Fixes #58Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/315Fix execution for Python 3.112023-03-27T10:39:01+02:00Stephan SeitzFix execution for Python 3.11Fixes execution on Python 3.11
Prevents the following error:
```
ImportError while loading conftest '/home/stephan/projects/pystencils/conftest.py'.
conftest.py:14: in <module>
from pystencils.cpu import cpujit
pystencils/__init__.p...Fixes execution on Python 3.11
Prevents the following error:
```
ImportError while loading conftest '/home/stephan/projects/pystencils/conftest.py'.
conftest.py:14: in <module>
from pystencils.cpu import cpujit
pystencils/__init__.py:10: in <module>
from .config import CreateKernelConfig
pystencils/config.py:19: in <module>
@dataclass
/usr/lib/python3.11/dataclasses.py:1220: in dataclass
return wrap(cls)
/usr/lib/python3.11/dataclasses.py:1210: in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
/usr/lib/python3.11/dataclasses.py:958: in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
/usr/lib/python3.11/dataclasses.py:815: in _get_field
raise ValueError(f'mutable default {type(f.default)} for field '
E ValueError: mutable default <class 'mappingproxy'> for field gpu_indexing_params is not allowed: use default_factory
```
I just did as I was told by Python :shrug:https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/314Gpu bufferfield fix2023-03-11T19:06:31+01:00Philipp SuffaGpu bufferfield fixSome small changes in the calculation of the field sizes to allow only buffered fields as well as only absolute access fields.
This is needed to allow AA-pattern and communication hiding for sparse kernels (ListLBM)Some small changes in the calculation of the field sizes to allow only buffered fields as well as only absolute access fields.
This is needed to allow AA-pattern and communication hiding for sparse kernels (ListLBM)Philipp SuffaPhilipp Suffahttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/313Add cache clearing function2023-02-23T17:20:18+01:00Markus HolzerAdd cache clearing functionFor developing purposes it is useful to have a cache-clearing functionFor developing purposes it is useful to have a cache-clearing functionMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/312Use common shape to resolve buffer access2022-12-22T09:41:41+01:00Markus HolzerUse common shape to resolve buffer accessPystencils assume that all fields have the same spatial shape. Thus the field access should also be resolved by one common field shape. This was violated in the GPU kernel creation and should be fixed with this MRPystencils assume that all fields have the same spatial shape. Thus the field access should also be resolved by one common field shape. This was violated in the GPU kernel creation and should be fixed with this MRMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/311Fix coverage badge2022-11-10T07:20:16+01:00Michael Kuronmkuron@icp.uni-stuttgart.deFix coverage badgeApply the same change as in https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/574.
If it works, the coverage should appear somewhere below on this page.Apply the same change as in https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/574.
If it works, the coverage should appear somewhere below on this page.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/310Fix display of coverage in Gitlab2022-11-04T12:20:08+01:00Michael Kuronmkuron@icp.uni-stuttgart.deFix display of coverage in GitlabThis is the same fix that @thoennes made in https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/573This is the same fix that @thoennes made in https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/573Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/309Improve FLOP counting function2022-11-07T10:05:52+01:00Markus HolzerImprove FLOP counting functionSince 'sp.UnevaluatedExpr' and 'DivFunc' are fundamental now for pystencils it is also important to introduce those functions in the FLOP countingSince 'sp.UnevaluatedExpr' and 'DivFunc' are fundamental now for pystencils it is also important to introduce those functions in the FLOP countingMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/308Remove depricated feature2022-10-25T12:52:06+02:00Markus HolzerRemove depricated featureRemoves deprecated featuresRemoves deprecated featuresMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/307Sane Defaults for CreateKernelConfig2022-10-25T11:16:04+02:00Markus HolzerSane Defaults for CreateKernelConfigBy default, the number type of float numbers should be the same as the default typeBy default, the number type of float numbers should be the same as the default typeMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/306Improve Vectorisation2023-05-02T10:07:49+02:00Markus HolzerImprove VectorisationThis MR fixes some bugs caused in the vectorisationThis MR fixes some bugs caused in the vectorisationMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/304Upgrade maximum supported SymPy version to 1.11.12022-10-10T22:32:05+02:00Markus HolzerUpgrade maximum supported SymPy version to 1.11.1Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/303Fix Regression from !3002022-10-10T22:31:56+02:00Markus HolzerFix Regression from !300In !300 all written field sizes are added to the SympyAssignment as unknown parameters. This solves the problem that all field sizes need to be passed as arguments when using NT stores with non-x86 architectures. However, it introduces t...In !300 all written field sizes are added to the SympyAssignment as unknown parameters. This solves the problem that all field sizes need to be passed as arguments when using NT stores with non-x86 architectures. However, it introduces two problems.
1. In all other cases these parameters are not used. Thus waLBerla fails in some cases when compiled with -Wall. Other than that it is not nice either to pass unused parameters.
2. For the GPU code generation problems arose with the usage of `get_parameters` in waLBerla:
https://i10git.cs.fau.de/pycodegen/pystencils/-/blob/master/pystencils/astnodes.py#L244
Overall it seems that the easiest way to fix the problem is to only pass the additional size arguments when needed and in no other cases.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/301Fix: `recursive_collect` now fails silently2022-07-28T15:52:03+02:00Frederik HennigFix: `recursive_collect` now fails silently`recursive_collect` used to throw an exception when an expression could not be written as a polynomial in the given symbols.
Now, it just fails quietly and returns the input expression unsimplified.`recursive_collect` used to throw an exception when an expression could not be written as a polynomial in the given symbols.
Now, it just fails quietly and returns the input expression unsimplified.https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/300Fix nontemporal stores on non-x86 for fields with variable size2022-10-10T22:31:57+02:00Michael Kuronmkuron@icp.uni-stuttgart.deFix nontemporal stores on non-x86 for fields with variable sizeFix the issue discussed in https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/553#note_19202Fix the issue discussed in https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/553#note_19202Markus HolzerMarkus Holzer