waLBerla issueshttps://i10git.cs.fau.de/walberla/walberla/-/issues2022-09-14T12:12:39+02:00https://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/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/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/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/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/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*.