When adding new kernels, a lot of manual work is currently needed
write the actual kernel generation in maintainer/walberla_kernels/generate_*.py
generate, format and copy kernels to src/walberla_bridge/src/lattice_boltzmann/generated_kernels
the following have to be done 4x per kernel, single/double precision, cpu/gpu
Add kernel cpp files to the CMake file there
include headers of the new kernels in kernel_traits.hpp
add the kernel classes in the KernelTraits classes for the respective architectures
lastly, kernels are currently imported into the actual LBWalberlaImpl class template via a using statement.
There is probably some potential for streamlingin:
the various kernel generation steps described in the readme in maintainer/walberla_kernels can probably mostly be put into a shell script
at the time of kernel generation, all information needed for the kernel_traits.hpp is in princicle known. We could generate that file from a Jinja template
Having one using statement per Kernel in LBWalberlaImpl could also be avoided, this would, however result in extra typenames throughout the code. Might still be worth it.
using Kernels = detail::KernelTraits<FloatType, Architecture>;
// ...
auto m_initial_pdf_setter = std::make_shared<typename Kernels::InitialPDFSetter>;
When adding new kernels, a lot of manual work is currently needed
maintainer/walberla_kernels/generate_*.py
src/walberla_bridge/src/lattice_boltzmann/generated_kernels
the following have to be done 4x per kernel, single/double precision, cpu/gpu
kernel_traits.hpp
KernelTraits
classes for the respective architecturesLBWalberlaImpl
class template via ausing
statement.There is probably some potential for streamlingin:
maintainer/walberla_kernels
can probably mostly be put into a shell scriptkernel_traits.hpp
is in princicle known. We could generate that file from a Jinja templateusing
statement per Kernel inLBWalberlaImpl
could also be avoided, this would, however result in extratypenames
throughout the code. Might still be worth it.