waLBerla issueshttps://i10git.cs.fau.de/walberla/walberla/-/issues2022-07-25T08:23:16+02:00https://i10git.cs.fau.de/walberla/walberla/-/issues/139Enable Python and codegen by default2022-07-25T08:23:16+02:00Michael Kuronmkuron@icp.uni-stuttgart.deEnable Python and codegen by defaultEnable `WALBERLA_BUILD_WITH_PYTHON`/`WALBERLA_BUILD_WITH_CODEGEN` by default if Python/lbmpy are found, respectively
Follow-up to !352Enable `WALBERLA_BUILD_WITH_PYTHON`/`WALBERLA_BUILD_WITH_CODEGEN` by default if Python/lbmpy are found, respectively
Follow-up to !3527.1Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/walberla/walberla/-/issues/130Improve pe Union2023-05-02T12:18:33+02:00Michael Kuronmkuron@icp.uni-stuttgart.deImprove pe UnionCurrent restrictions that I noticed:
- [ ] A union of two overlapping bodies has an incorrect volume, mass and inertia tensor. Overlap should either be checked for and warned about, or the overlap volume should be estimated numerically ...Current restrictions that I noticed:
- [ ] A union of two overlapping bodies has an incorrect volume, mass and inertia tensor. Overlap should either be checked for and warned about, or the overlap volume should be estimated numerically and mass and inertia be corrected accordingly.
- [ ] Cryptic errors happen when a union is created from bodies spread across a block boundary.
Further restrictions that @eibl mentioned to me:
- [ ] Dynamic creation and splitting of unions in parallel is problematic.
- [ ] Unclear collision handling because concave objects can collide in multiple points simultaneously.
Regarding the last point: I guess you can even have simultaneous collisions without unions. E.g. cube-cube and cube-plane (face to face), cube-cylinder, plane-cylinder and cyclinder-cylinder (face to side or face to face), or sphere-torus (moving the sphere through the center of the torus).https://i10git.cs.fau.de/walberla/walberla/-/issues/126Investige usage of CUDA graphs to reduce kernel call overhead2020-07-26T21:38:21+02:00Stephan SeitzInvestige usage of CUDA graphs to reduce kernel call overheadMarco had the idea to use this in the CUDA backend for Petalisp. But maybe it's also useful in waLBerla timeloops.
https://developer.nvidia.com/blog/cuda-graphs/
It effectively tries to reduce call overhead of kernels when you repeated...Marco had the idea to use this in the CUDA backend for Petalisp. But maybe it's also useful in waLBerla timeloops.
https://developer.nvidia.com/blog/cuda-graphs/
It effectively tries to reduce call overhead of kernels when you repeatedly call the same group of kernels. Maybe not as relevant, since bottleneck should be communication not managing the CUDA kernels and our kernels are not exactly "short-running"-https://i10git.cs.fau.de/walberla/walberla/-/issues/113Provide same behavior of generated lattice model to built-in ones2022-07-25T08:23:21+02:00Christoph RettingerProvide same behavior of generated lattice model to built-in onesWhen generating a lattice model with lbmpy_walberla, the behavior is in some cases not the same as for the walberla-built-in lattice models.
This is a (possibly incomplete) list of differences:
* E.g. for checkpointing, the PDF field is ...When generating a lattice model with lbmpy_walberla, the behavior is in some cases not the same as for the walberla-built-in lattice models.
This is a (possibly incomplete) list of differences:
* E.g. for checkpointing, the PDF field is save to a file, and at the same time the lattice model is also packed. In waLBerla, the lattice model has a valid `pack` method (by calling the `pack` functions of the collision and the force model ) that really packs all infos (relaxation rates, forces,..) of the lattice model into the buffer. When reading the checkpoint file, these parameters will be unpacked and initialized correctly. This is NOT the case for the generated one since no parameters are packed/unpacked meaning that the user has to take care himself to properly initialize the lattice model's parameters.
* The same problem is probably also relevant for adaptive mesh refinement when PDF field block data is sent from one block to another, together with the lattice model.
As these things can easily happen totally unnoticed, this is considered highly dangerous and should be changed.7.1Christoph RettingerChristoph Rettingerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/109Use mdspan instead of Field for portability of codegen beyond Walberla2022-09-14T12:12:39+02:00Michael Kuronmkuron@icp.uni-stuttgart.deUse mdspan instead of Field for portability of codegen beyond Walberla@bauer pointed out that C++23 wil have `std::mdspan`, a non-owning multidimensional array view. A reference implementation that works with C++11 and higher is already available: https://github.com/kokkos/mdspan.
This could be used at th...@bauer pointed out that C++23 wil have `std::mdspan`, a non-owning multidimensional array view. A reference implementation that works with C++11 and higher is already available: https://github.com/kokkos/mdspan.
This could be used at the interface between Walberla and pystencils‘ generated code and would allow pystencils_walberla to be used with other (non-Walberla) software. Right now, that interface uses `walberla::field::Field`.https://i10git.cs.fau.de/walberla/walberla/-/issues/108Make Codegen Safer2020-03-18T08:53:11+01:00Christoph RettingerMake Codegen SaferBy introducing more and more (lbmpy/pystencils but also mesa_pd) codegen stuff in waLBerla, the problem arises that changes made in lbmy or pystencils might ultimately also affect the outcome of the codegen procedure, i.e. the generated ...By introducing more and more (lbmpy/pystencils but also mesa_pd) codegen stuff in waLBerla, the problem arises that changes made in lbmy or pystencils might ultimately also affect the outcome of the codegen procedure, i.e. the generated kernel/lattice model.
The problem is not only that these changes are made in other repositories, but also that changes in some files there can not easily be linked to the functionality that is used in the codegen scripts, i.e. it is not intuitively clear by looking at commit changes that this might affect my generated kernel.
One solution could be, that if I want to make sure that a certain kernel does exactly what I have in mind, I have to define a certain input (e.g. 27 PDFs in a single cell) and compute the output with my kernel, for which I know it is correct.
This pair of input and output is then put inside the codegen script file and every time I generate a kernel, it is checked that the output of the newly generated kernel matches the formerly given one.
In some cases, this could also be done symbolically, but the issue arises that different optimizations might lead to a different symbolic representation, even though the outcome of the actual computation sis till the same.
So it would be great to introduce a checkKernel(kernel, input, output) function, to e.g. lbmpy_walberla. Then, initial (and correct) input-output-pairs for the currently existing codegen things in waLBerla have to be defined. And then the check function is used in all codegen scripts to assert that the behavior is still the same. The input data set should be complex enough to cover most cases (e.g. not all zeros), maybe even random.https://i10git.cs.fau.de/walberla/walberla/-/issues/94Zero-centering of stored PDF values is not well documented and unclear2022-11-17T15:09:55+01:00Christoph RettingerZero-centering of stored PDF values is not well documented and unclearIn waLBerla, the LBM PDF values are either stored regularly, i.e. text-book like, or "centered around 0", i.e. just storing the deviation from the corresponding lattice weight.
The decision is done based on the lattice model with the com...In waLBerla, the LBM PDF values are either stored regularly, i.e. text-book like, or "centered around 0", i.e. just storing the deviation from the corresponding lattice weight.
The decision is done based on the lattice model with the compressible flag: true leads to regular PDF values, whereas false (=incompresisble) leads to centered PDF values.
The seemingly only place where this is noted is in a comment in src/lbm/field/PdfField.h but it is a very important aspect to realize when implementing own algorithms etc.
This should be documented better in some central place or a tutorial (and this issue is supposed to be a temporary documentation of this behavior).
Furthermore, it should be evaluated whether or not this centering might also make sense for the compressible case, as the only reason for centering seems to be floating point accuracy. Or is there another reason not to do it?
For a clearer self-documentation, one should add a flag to the lattice model like 'zero-centered' and this flag should be used instead of the compressible flag to check for the centering and its implications.7.1Christoph RettingerChristoph Rettingerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/89make UniqueID stateless2022-08-11T10:09:52+02:00Sebastian Eiblmake UniqueID statelessCurrently UniqueID has a state which is not stored in checkpoint&restore scenarios. This may cause id collisions in a restarted simulation.
I think this is only relevant for the pe when you create new particles after a restart.Currently UniqueID has a state which is not stored in checkpoint&restore scenarios. This may cause id collisions in a restarted simulation.
I think this is only relevant for the pe when you create new particles after a restart.7.1https://i10git.cs.fau.de/walberla/walberla/-/issues/81pe_coupling tutorial2022-07-25T08:23:31+02:00Michael Kuronmkuron@icp.uni-stuttgart.depe_coupling tutorialThere should be a pe_coupling tutorial that shows how to set up a simulation with the momentum exchange method. Right now there are separate tutorials for pe and lbm, but coupling the two is highly nontrivial for a novice user.There should be a pe_coupling tutorial that shows how to set up a simulation with the momentum exchange method. Right now there are separate tutorials for pe and lbm, but coupling the two is highly nontrivial for a novice user.7.1Christoph RettingerChristoph Rettingerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/78CMake cleanup/rewrite2022-07-25T08:23:35+02:00Michael Kuronmkuron@icp.uni-stuttgart.deCMake cleanup/rewrite- Decide on a minimum CMake version (e.g. 3.10, as included by Ubuntu 18.04) and then make use of all the new features available to simplify our build system.
- Make it easier to use of Walberla as a library in external projects.
- Rewri...- Decide on a minimum CMake version (e.g. 3.10, as included by Ubuntu 18.04) and then make use of all the new features available to simplify our build system.
- Make it easier to use of Walberla as a library in external projects.
- Rewrite the whole build system according to current CMake best practices.
- Eliminate all the hacks for library detection on old systems.
- Make each submodule either header-only or completely compiled into a library (e.g. using explicit template instantiation if the set of possible types is small). The current state where most submodules are like 10% compiled just combines the downsides of both (long compile times, requirement of linking).7.1https://i10git.cs.fau.de/walberla/walberla/-/issues/77Replace iterator macros with lambdas2022-07-25T08:23:37+02:00Michael Kuronmkuron@icp.uni-stuttgart.deReplace iterator macros with lambdasOriginal inspiration: OpenMP pragmas inside WALBERLA_FOR_ALL_CELLS_ macros are broken (#5). Also using commas outside of parentheses (e.g. when separating multiple template parameters) in the body of a WALBERLA_FOR_ALL_CELLS_ macro leads...Original inspiration: OpenMP pragmas inside WALBERLA_FOR_ALL_CELLS_ macros are broken (#5). Also using commas outside of parentheses (e.g. when separating multiple template parameters) in the body of a WALBERLA_FOR_ALL_CELLS_ macro leads to confusing error messages.
Macros are not very C++-like. Since C++11 brought structures like `std::for_each` and lambdas, there is a good language-level alternative.
There might be performance implications when a compiler doesn‘t properly inline the lambda. Recent compilers should be okay because a lot of the STL algorithms depend on it too, but it needs to be checked that performance doesn‘t degrade.7.1https://i10git.cs.fau.de/walberla/walberla/-/issues/52Rework config file and command line argument substitution2022-07-25T08:23:40+02:00Christoph RettingerRework config file and command line argument substitutionIt is possible to specify a config file and further command line arguments that replace variables set in the config file, allowing for parameter studies with the same config file. See core/Environment.h and core/config/Create.h.
However,...It is possible to specify a config file and further command line arguments that replace variables set in the config file, allowing for parameter studies with the same config file. See core/Environment.h and core/config/Create.h.
However, the documentation is misleading (which order should there be: "configFile var1 var2" or "var1 var 2 configFile").
Also, there seem to be two replacement mechanisms:
Directly in the create function (Create.cpp) via
`config->addValueReplacement( &argv[i][1], argv[i+1] )`
and then in the later called function
`substituteCommandLineArgs( *config, argc, argv )`
Both seem to require differently formatted command line arguments.
Also, it seems ambiguous to have two mechanisms achieving the same thing.7.1Christoph RettingerChristoph Rettingerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/40Write a test to check bounding boxes.2022-07-25T08:23:43+02:00Sebastian EiblWrite a test to check bounding boxes.7.1https://i10git.cs.fau.de/walberla/walberla/-/issues/37Change return type of FieldIterator conversion (iterator to const_iterator)2022-07-25T08:23:46+02:00Tobias Schruffschruff@iww.rwth-aachen.deChange return type of FieldIterator conversion (iterator to const_iterator)In my code, I could not do the following
```c
template< typename Field_T >
void foo( Field_T & field )
{
auto * buffer = field.clone();
for( typename Field_T::const_base_iterator it = field.begin(); ... )
{
buffer->( it.c...In my code, I could not do the following
```c
template< typename Field_T >
void foo( Field_T & field )
{
auto * buffer = field.clone();
for( typename Field_T::const_base_iterator it = field.begin(); ... )
{
buffer->( it.cell() ) = ... calculate something based on *it (plus some neighbors) ...
}
field.swapDataPointers( buffer );
}
```
because the compiler would not create a const_iterator (or const_base_iterator) from a non-const field. I'm not sure if this is a bug ( or a feature ;), but it would be handy to create a const_iterator from a non-const field in some situations, like the one above. Or can `foo` be implemented in a better/more efficient way?
**Proposal**
If the custom FieldIterator conversion is changed from
```c
operator const FieldIterator<const T, fieldFSize> & () const {
const FieldIterator<const T, fieldFSize> * ptr;
ptr = reinterpret_cast< const FieldIterator<const T, fieldFSize>* > ( this );
return *ptr;
}
```
to
```c
operator FieldIterator<const T, fieldFSize> () {
FieldIterator<const T, fieldFSize> * ptr;
ptr = reinterpret_cast< FieldIterator<const T, fieldFSize>* > ( this );
return *ptr;
}
```
the problem disappears (at the cost of creating a copy of the iterator).7.1Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/25walberla::geometry::getClosestLineBoxPoints produces wrong results2021-03-29T18:42:28+02:00Tobias Leemannwalberla::geometry::getClosestLineBoxPoints produces wrong resultsFor some combinations of Capsules and Boxes the analytical collision detection of PE seems to yield wrong results.
This is probably caused by a bug in the function `walberla::geometry::getClosestLineBoxPoints`.
Code Example to reprodu...For some combinations of Capsules and Boxes the analytical collision detection of PE seems to yield wrong results.
This is probably caused by a bug in the function `walberla::geometry::getClosestLineBoxPoints`.
Code Example to reproduce:
The Capsule has radius 3, length 6 and is not rotated and translated, so its center line runs from (-3,0,0) to (3,0,0).
The Box has size (3, 1.5, 1.5) and is somehow rotated and translated.
```
Vec3 box_pos(real_t(-2.46404), real_t(2.90053), real_t(-2.177));
Quat box_rot(real_t(0.712691),real_t(-0.509519),real_t(0.0466145), real_t(0.479884));
//Corresponding Bodies
Box box(0, 0, box_pos, Vec3(0,0,0), box_rot, Vec3(3, real_t(1.5), real_t(1.5)), iron, false, true, false);
Capsule cap(1, 1, Vec3(0,0,0), Vec3(0,0,0), Quat(), real_t(3.0), real_t(6.0), iron, false, true, false);
//This is how getClosestLineBoxPoints is called in the collide-function:
Vec3 line_point, box_point;
walberla::geometry::getClosestLineBoxPoints( Vec3(3,0,0), Vec3(-3,0,0), box_pos, box_rot.toRotationMatrix(),
Vec3(real_t(3), real_t(1.5), real_t(1.5)), line_point, box_point);
std::cerr << "Result: Line-Point " << line_point ", Box-Point " << box_point << std::endl;
```
This results in the following output:
`Result: Line-Point <3,0,0>, Box-Point <-1.66899,2.22324,-1.94998>`
This result is wrong, because if you rotate and translate the Corner (-1.5,-0.75,-0.75)(in box local coordinates) e.g. by
`std::cerr << "Corner Position of Box: " << box_pos+box_rot.rotate(Vec3(real_t(-1.5), real_t(-0.75), real_t(-0.75))) << std::endl;`
you obtain the point (-2.40108,1.35235,-1.18999) which is the nearest point of the box to the line. The nearest point on the line would then be (-2.40108, 0, 0).
The return of the incorrect points in this case results in a failure to detect the collision between the Box and the Capsule (which has a large penetration depth of about 1.1986).https://i10git.cs.fau.de/walberla/walberla/-/issues/14field::refinement::PackInfo should permit specifying number of ghost layers t...2019-11-07T14:23:10+01:00Michael Kuronmkuron@icp.uni-stuttgart.defield::refinement::PackInfo should permit specifying number of ghost layers to communicateFor uniform grids, `field::communication::PackInfo`'s constructor has an optional argument `numberOfGhostLayers` that specifies how many ghost layers should be exchanged. If it is not given, then all ghost layers are exchanged.
For re...For uniform grids, `field::communication::PackInfo`'s constructor has an optional argument `numberOfGhostLayers` that specifies how many ghost layers should be exchanged. If it is not given, then all ghost layers are exchanged.
For refined grids, `field::refinement::PackInfo`, having otherwise identical functionality to its non-refined counterpart, does not permit specifying the number of ghost layers to exchange. In fact, it does not even exchange all ghost layers, but only communicates one layer of the coarse field to two layers of the fine field. Functionality to specify the number of ghost layers should be added. For consistency with non-refined simulations, the number of ghost layers should be specified from the perspective of the coarse field, so if `2` is given, 2 ghost layers of the coarse grid should exchange data with 4 ghost layers of the fine grid.https://i10git.cs.fau.de/walberla/walberla/-/issues/13Make the timeloop more powerful. lbm::refinement::TimeStep duplicates much of...2019-11-07T14:23:05+01:00Michael Kuronmkuron@icp.uni-stuttgart.deMake the timeloop more powerful. lbm::refinement::TimeStep duplicates much of the functionality of timeloop::SweepTimeloopFor refined simulations, one needs to use `lbm::refinement::TimeStep`, which duplicates much of the functionality of the regular `timeloop::SweepTimeloop`. The `lbm::refinement::TimeStep` is then attached to a `timeloop::SweepTimeloop`. ...For refined simulations, one needs to use `lbm::refinement::TimeStep`, which duplicates much of the functionality of the regular `timeloop::SweepTimeloop`. The `lbm::refinement::TimeStep` is then attached to a `timeloop::SweepTimeloop`. This is not very elegant and the two should be merged so that one does not end up with multiple `timing::TimingPool` objects, gets the same amount of debug logging, etc. Further problems include that `lbm::refinement::TimeStep` does not provide callbacks in all desirable places (I would for example need one each after `(startCommunication|wait)(CoarseToFine|FineToCoarse|EqualLevel)` ).
Perhaps `lbm::refinement::TimeStep` can be replaced with a set of helper functions that add the appropriate functors to an (enhanced) `timeloop::SweepTimeloop`.
Additionally, `timeloop::SweepTimeloop` should itself conform to the concept of `timeloop::Timeloop::SelectableFunc` so that timeloops can be nested. This would be useful for things that have internal iterations, like the PDE solvers.Christoph RettingerChristoph Rettingerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/12Unify refinement selection for static and dynamic grid refinement2019-11-07T14:22:59+01:00Michael Kuronmkuron@icp.uni-stuttgart.deUnify refinement selection for static and dynamic grid refinementCurrently, the static grid refinement's `SetupBlockForest` takes a *refinement selection function*, where markers are set to specify which parts of the domain need further refinement. The dynamic grid refinement's `BlockForest`, on the ...Currently, the static grid refinement's `SetupBlockForest` takes a *refinement selection function*, where markers are set to specify which parts of the domain need further refinement. The dynamic grid refinement's `BlockForest`, on the other hand, takes a *minimum target level determination function*, which directly specifies the desired level of refinement.
This means that switching from static to dynamic refinement requires implementing another function. It also means that simulations with dynamic refinement need to either implement both or only set up the root blocks as part of the static refinement and leave the actual work to the dynamic refinement. Static refinement should however not be dropped from Walberla as it may be sufficient for many simulations and has the advantage that the block forest setup can be performed independently of the simulation and saved to a file.
I therefore propose that an adapter be created that takes a *minimum target level determination function* and sets markers appropriately so it can be used with static refinement. Alternatively, `SetupBlockForest` could also be modified to alternatively accept a *minimum target level determination function* directly instead of requiring a *refinement selection function*.https://i10git.cs.fau.de/walberla/walberla/-/issues/10Multigrid PDE solver2023-03-29T20:05:37+02:00Michael Kuronmkuron@icp.uni-stuttgart.deMultigrid PDE solverWalberla should eventually have a multigrid PDE solver. This should also enable solving PDEs on refined grids. As requested in software/walberla#15, it should optionally be possible to specify the full sparse matrix for the left-hand sid...Walberla should eventually have a multigrid PDE solver. This should also enable solving PDEs on refined grids. As requested in software/walberla#15, it should optionally be possible to specify the full sparse matrix for the left-hand side instead of just giving stencil weights.
Strategy:
1. [x] Basic multigrid with direct coarsening and no boundary conditions
* [x] Add stencil field support to existing PDE solvers (software/walberla#15), as this is required for the following steps.
* [x] Implement Galerkin Coarsening
* [x] Locally modify the stencil to take into account boundary conditions
* [ ] Grid refinement
* [ ] Make sure RBGS work on refined grids. We can assume that all blocks have the same coarsest resolution.
* [ ] Adapt V-cycle so that for its finest levels, it can use the block's resolution if no grid with the needed resolution is available.
* [ ] For dynamic refinement, need to recreate the coarser levels of the V-cycle (solution, rhs, residual, stencil field) whenever the refinement changes.Richard AngersbachRichard Angersbachhttps://i10git.cs.fau.de/walberla/walberla/-/issues/8Problem with PythonCallbacks2022-07-25T08:23:48+02:00Martin BauerProblem with PythonCallbacks- callbacks are set as attributes in walberla_cpp.callbacks module
- if now two different modules with callbacks are imported using
PythonCallback cb1( "file1.py", "function1"); and
PythonCallback cb2( "fil...- callbacks are set as attributes in walberla_cpp.callbacks module
- if now two different modules with callbacks are imported using
PythonCallback cb1( "file1.py", "function1"); and
PythonCallback cb2( "file2.py", "function1");
cb1(); runs actually the wrong cb2 (since it overrides the walberla_cpp.callbacks.function1 entry7.1Markus HolzerMarkus Holzer