waLBerla issueshttps://i10git.cs.fau.de/walberla/walberla/-/issues2024-01-29T12:17:02+01:00https://i10git.cs.fau.de/walberla/walberla/-/issues/239Dynamic load balancing: Refresh function seems to not communicate the flag fi...2024-01-29T12:17:02+01:00Philipp SuffaDynamic load balancing: Refresh function seems to not communicate the flag field correctlyWhen using the blockforest refresh function for dynamic load balancing, it seems not to communicate the "uidToFlag" map of the flag Field. So the flags in the flag field are still set correctly but the connection to the FlagUIDs seems to...When using the blockforest refresh function for dynamic load balancing, it seems not to communicate the "uidToFlag" map of the flag Field. So the flags in the flag field are still set correctly but the connection to the FlagUIDs seems to be lost.Philipp SuffaPhilipp Suffahttps://i10git.cs.fau.de/walberla/walberla/-/issues/238import waLBerla hangs after installation2024-02-12T15:19:48+01:00Pedro Santos Nevesimport waLBerla hangs after installationHi waLBerla developers and contributors!
With other colleagues in the EESSI and MultiXscale projects, we are trying to build and deploy optmized waLBerla v6.1 installations and ran into an issue when building it with two specific toolch...Hi waLBerla developers and contributors!
With other colleagues in the EESSI and MultiXscale projects, we are trying to build and deploy optmized waLBerla v6.1 installations and ran into an issue when building it with two specific toolchains that we'd like to report and hopefully get your input on.
A summary of the issue:
We are building waLBerla through EasyBuild using the [`foss2022b`](https://github.com/easybuilders/easybuild-easyconfigs/pull/19324) and [`foss2023a`](https://github.com/easybuilders/easybuild-easyconfigs/pull/19252) toolchains with two identical easyconfig files. With either toolchain the installation proceeds until the sanity check step which simply runs `python -c import waLBerla`, upon which the system hangs. We see this happen [on the EasyBuild test clusters](https://github.com/easybuilders/easybuild-easyconfigs/pull/19252#issuecomment-1820653972) but not on our personal laptops or in the HPC at the University of Groningen.
We tried to change the sanity check to `mpirun -np 1 python -c "import waLBerla"` in the chance that the issue was with the test cluster's environment, but the same hang occurs.
One successful workaround is to set `UCX_LOG_LEVEL=info` in the sanity check so that it reads `UCX_LOG_LEVEL=info python -c "import waLBerla"`. We don't know why changing the log level of `UCX` resolves this problem, and my colleague who discovered this has also opened a ticket about it in the `UCX` repo [here](https://github.com/openucx/ucx/issues/9532).
Another workaround seems to be importing `mpi4py` before waLBerla. This is surprising, because `mpi4py` is not a dependency of waLBerla. We would rather not add `mpi4py` as a dependency for this issue, especially without knowing the consequences of this.
Given that we were only seeing this problem in the EasyBuild test clusters and not in other systems, and also the fact that the `UCX` workaround seems to work for the [EESSI test clusters](https://github.com/EESSI/software-layer/pull/421), we assumed `import waLBerla` was likely hanging due to some quirk of the EasyBuild test clusters. However, we received a [report ](https://github.com/easybuilders/easybuild-easyconfigs/pull/19324/#issuecomment-1857832565) from another EasyBuild maintainer with a notice of this problem in another system. Because of this, we are now not convinced that whatever is causing this has to do with the EasyBuild clusters and their environment.
We have a [summary](https://gitlab.com/eessi/support/-/issues/20) of our attempts in our support portal, where you can find more details.
Would you have any idea of what could be causing this, or have you perhaps encountered something similar in the past? We'd love your input as we're quite confused about this problem. Thanks in advance!https://i10git.cs.fau.de/walberla/walberla/-/issues/237clang-tidy used to ignore .h files2023-11-09T14:59:33+01:00Dominik Thoennesdominik.thoennes@fau.declang-tidy used to ignore .h filesI think that the clang-tidy script ignored `.h` files in the past.
This means that these files were not checked and there are lots of warnings after the update.
I disabled the job in the pipeline for now.
https://i10git.cs.fau.de/walberl...I think that the clang-tidy script ignored `.h` files in the past.
This means that these files were not checked and there are lots of warnings after the update.
I disabled the job in the pipeline for now.
https://i10git.cs.fau.de/walberla/walberla/-/jobs/1135823https://i10git.cs.fau.de/walberla/walberla/-/issues/236Documentation on overriding parameter values on the command line is incorrect2023-12-18T15:37:00+01:00Marcus MohrDocumentation on overriding parameter values on the command line is incorrectHi,
the Doxygen documentation for the `Environment` class states that
> If command line parameters are present they have to contain at least the path to the configuration file and optionally pairs of param-value:
"-myParameter myValue"
...Hi,
the Doxygen documentation for the `Environment` class states that
> If command line parameters are present they have to contain at least the path to the configuration file and optionally pairs of param-value:
"-myParameter myValue"
>
> These values are then substituted in configuration files at positions marked with $(myParameter)
In my tests (with [HyTeG](https://i10git.cs.fau.de/hyteg/hyteg) where we use a lot of your nice core functionalities) this unfortunately fails. After some digging trough your code I am very confident that the documentation is actually incorrect. It should probably read:
```
-blockName.parameterName=parameterValue
```
Cheers
MarcusPhilipp SuffaPhilipp Suffahttps://i10git.cs.fau.de/walberla/walberla/-/issues/235Boundary collection is not supporting ExtrapolationOutflow boundary on GPU2023-10-23T11:22:45+02:00Philipp SuffaBoundary collection is not supporting ExtrapolationOutflow boundary on GPUBoundary collection is not supporting ExtrapolationOutflow boundary on GPU, as one argument is missing at the constructor call in BoundaryCollection.hBoundary collection is not supporting ExtrapolationOutflow boundary on GPU, as one argument is missing at the constructor call in BoundaryCollection.hMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/212Define FlagUIDs in the BoundaryCollection for reuse in App2023-06-21T11:38:45+02:00Philipp SuffaDefine FlagUIDs in the BoundaryCollection for reuse in AppIt could be useful to define the FlagUIDs, which are first set in the generation file, in the BoundaryCollection, so that they can be further used in the application file.
So if one defined a UBB, NoSlip and FixedDensity boundary in the...It could be useful to define the FlagUIDs, which are first set in the generation file, in the BoundaryCollection, so that they can be further used in the application file.
So if one defined a UBB, NoSlip and FixedDensity boundary in the generation file, the BoundaryCollection could look like:
```
namespace walberla{
namespace lbm {
const FlagUID noSlipFlagUID("NoSlip");
const FlagUID UBBFlagUID("UBB");
const FlagUID FixedDensityFlagUID("FixedDensity");
class PSMBoundaryCollection
{
....
```Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/211change default log level2023-06-16T11:41:24+02:00Dominik Thoennesdominik.thoennes@fau.dechange default log levellog level `Progress` is too verbose for a lot of apps.
So we should change the default to `Info`log level `Progress` is too verbose for a lot of apps.
So we should change the default to `Info`Christoph AltChristoph Althttps://i10git.cs.fau.de/walberla/walberla/-/issues/210CodeGen conditional statements2023-04-06T08:16:08+02:00brendan-watersCodeGen conditional statementsHi All,
Not sure if this is the best place for this question (please advise if not), but is there any way to assign a ternary operator through the CodeGen interface? A model I am implementing essentially requires the step:
```
eqs = [...Hi All,
Not sure if this is the best place for this question (please advise if not), but is there any way to assign a ternary operator through the CodeGen interface? A model I am implementing essentially requires the step:
```
eqs = [Assignment(phi, phi_num),
Assignment(phi_adj, [conditional]), # Conditional should be -> (phi > 0.0) ? phi : 0.0;
.....
]
```
Any pointers in the right direction would be greatly appreciated.
Many Thanks!https://i10git.cs.fau.de/walberla/walberla/-/issues/209Code Quality Days 2.5. + 3.5.2023-05-02T09:36:09+02:00Dominik Thoennesdominik.thoennes@fau.deCode Quality Days 2.5. + 3.5.Hi,
this issue is intended to provide an overview of the open issues we could work on during the code quality days.
The current plan is to have this for two days.
Please feel free to add more information.
Poll for the date:
https://ter...Hi,
this issue is intended to provide an overview of the open issues we could work on during the code quality days.
The current plan is to have this for two days.
Please feel free to add more information.
Poll for the date:
https://terminplaner6.dfn.de/en/p/6683ec971fb22b9928e1ff6d3ae6b412-196072
| topic | comment/explanation | related issues |
| --- | --- | --- |
|Cleanup | Check very old issues (> 2 years) to see if these are still relevant | |
| Remove Boost | | #190 |
| fix metis/parmetis integration | | #195 |
| improve logging | | #178 |
| Unify Communication | CPU and GPU communication schemes are vastly similar | #196 |
| Better GPU integration | GPU usage should be integrated like MPI for example | !565 |
| Use SoA by default | Although SoA is mostly better it is not the default in waLBerla | #182 |
| Boundaries | Different topics on boundaries | #203 #173 #170 #3 |
https://docs.google.com/spreadsheets/d/1chiE5PCNcuokjp7Q3MyClaKQlDO2GqmaljPfJlIhH20/edit#gid=0https://i10git.cs.fau.de/walberla/walberla/-/issues/208Request: Add documentation or an example for Multigrid + CUDA2023-03-30T18:32:57+02:00SimonHRequest: Add documentation or an example for Multigrid + CUDAHi,
I'm trying to solve a simple model Problem using your Multigrid implementation on GPU with Galerkin coarsening, however there does not appear to be a good information source on this. Currently I'm using `test/pde/MGTest` as a baseli...Hi,
I'm trying to solve a simple model Problem using your Multigrid implementation on GPU with Galerkin coarsening, however there does not appear to be a good information source on this. Currently I'm using `test/pde/MGTest` as a baseline but having trouble to convert everything to use GPU buffers instead of GPU ones. E.g. for a simple field I found `cuda::addGPUFieldToStorage` is the equivalent to `field::addToStorage` but what about `pde::VCycles<Stencil_T>::StencilField_T`, `pde::CoarsenStencilFieldsGCA<Stencil_T>`, ` pde::ResidualNormStencilField< Stencil_T >`, ...?
I found [this publication from 2013](https://link.springer.com/chapter/10.1007/978-3-642-16405-7_26#chapter-info) but it seems like the associated code is missing from `apps/benchmarks` unlike the documentation states. Or I just didn't find it there.
Could you help me out, point me to the right direction?
Plus, for the long term, it would be really nice if you could add an example to the repository and/or add information to the documentation.
Thanks!Richard AngersbachRichard Angersbachhttps://i10git.cs.fau.de/walberla/walberla/-/issues/207x86 half precision (float16) support2023-06-28T15:19:15+02:00Nils Kohlx86 half precision (float16) supportThis issue describes the process of adding experimental support for half precision (float16) on x86.
A nice description of what can be expected: https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point
Some com...This issue describes the process of adding experimental support for half precision (float16) on x86.
A nice description of what can be expected: https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point
Some compilers provide support for IEEE 754-2008 half precision (binary16) floating point formats on x86.
Most current systems do not implement the necessary arithmetic instructions to work directly on float16, but instead promote to float32 (single precision) before computations and quantize to float16 afterwards. However, storage and interchange is performed in the 16 bit format, thus memory-bound code could benefit, if half precision is sufficient numerically.
Commit 238a069cd8e509ad2d583e0ee0163f9a88bd7b03 adds experimental support for clang >= version 15.
New type aliases `half` and `float16` are defined in [DataTypes.h](https://i10git.cs.fau.de/walberla/walberla/-/blob/238a069cd8e509ad2d583e0ee0163f9a88bd7b03/src/core/DataTypes.h#L171).
Some caveats / remaining issues:
* `float16` variables have to be cast to `float` or `double` before formatting (i.e. when writing to `stdout`)
* almost no `walberla` feature has been tested with `float16` yet
Other compilers might also support such features, but have not been evaluated yet.
A small app that checks `float16` support has been implemented with [CheckFP16.cpp](https://i10git.cs.fau.de/walberla/walberla/-/blob/238a069cd8e509ad2d583e0ee0163f9a88bd7b03/apps/tools/MixedPrecision/CheckFP16.cpp).
Also, a new CMake option `WALBERLA_BUILD_WITH_HALF_PRECISION_SUPPORT` has been added. This does **not** set `real_t` to `float16` but simply enables `float16`, and the corresponding type aliases. Note that usually some intrinsics have to be enabled on x86, so `WALBERLA_OPTIMIZE_FOR_LOCALHOST` generally has to be enabled. Otherwise you will likely encounter linker errors.
First benchmarks with LIKWID show that autovectorization using single precision AVX intrinsics seems to work nicely. Run `likwid-perfctr` on [CheckFP16.cpp](https://i10git.cs.fau.de/walberla/walberla/-/blob/238a069cd8e509ad2d583e0ee0163f9a88bd7b03/apps/tools/MixedPrecision/CheckFP16.cpp) to see if that also works on your machine.Nils KohlNils Kohlhttps://i10git.cs.fau.de/walberla/walberla/-/issues/206PythonWalberlaTest fails with Numpy 1.202023-03-10T08:10:55+01:00Dominik Thoennesdominik.thoennes@fau.dePythonWalberlaTest fails with Numpy 1.20The `PythonWalberlaTest` fails if Numpy is higher than 1.20 with the following error:
```
root@8b4ce2be910e:/build# ctest -R PythonWalberlaTest --output-on-failure
Test project /build
Start 370: PythonWalberlaTest
1/1 Test #370: Pyt...The `PythonWalberlaTest` fails if Numpy is higher than 1.20 with the following error:
```
root@8b4ce2be910e:/build# ctest -R PythonWalberlaTest --output-on-failure
Test project /build
Start 370: PythonWalberlaTest
1/1 Test #370: PythonWalberlaTest ...............***Failed 0.31 sec
..........E...
======================================================================
ERROR: test_gather (test_field.FieldModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/walberla/python/waLBerla_tests/test_field.py", line 55, in test_gather
wlb.field.addToStorage(blocks, "test", dtype=np.int, fSize=3)
File "/usr/local/lib/python3.10/dist-packages/numpy/__init__.py", line 305, in __getattr__
raise AttributeError(__former_attrs__[attr])
AttributeError: module 'numpy' has no attribute 'int'.
`np.int` was a deprecated alias for the builtin `int`. To avoid this error in existing code, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
``https://i10git.cs.fau.de/walberla/walberla/-/issues/205Juwels-Booster: selectDeviceBasedOnMpiRank() presumably assigns the wrong hos...2023-04-05T13:49:07+02:00Philipp SuffaJuwels-Booster: selectDeviceBasedOnMpiRank() presumably assigns the wrong host memory to the deviceThe function selectDeviceBasedOnMpiRank() seems to assign all devices (GPUs) on a node to the same host memory.
This could cause performance issues for CPU to GPU communication (cudaMemcopy), because GPUs are not communicating to their c...The function selectDeviceBasedOnMpiRank() seems to assign all devices (GPUs) on a node to the same host memory.
This could cause performance issues for CPU to GPU communication (cudaMemcopy), because GPUs are not communicating to their closest host memory.
So if you allocate 4 GPUs on a node and call the program with 4 MPI processes, all 4 GPUs are assigned to the same MPI process memory (of process 1) by cudaSetDevice().
This is the case, because the function gpuGetDeviceCount() returns 1 instead of 4 devices (GPUs).
This behavior is only tested for juwels-booster so far, further investigation is needed...https://i10git.cs.fau.de/walberla/walberla/-/issues/204Is there a LBM grid refinement example on the GPU?2023-09-27T21:54:03+02:00ahmedIs there a LBM grid refinement example on the GPU?Thanks a lot for making this great library open-source with such high-quality code!
I was wondering if there's a 3D LBM grid refinement refinement that runs on the GPU. I saw a a LBM grid refinement example under `apps\benchmarks\Adapti...Thanks a lot for making this great library open-source with such high-quality code!
I was wondering if there's a 3D LBM grid refinement refinement that runs on the GPU. I saw a a LBM grid refinement example under `apps\benchmarks\AdaptiveMeshRefinementFluidParticleCoupling` but I think it only runs in parallel on the CPU (correct me if I'm wrong). What I'm trying to find is running LBM on a non-uniform static mesh that doesn't change over time i.e., not AMR.https://i10git.cs.fau.de/walberla/walberla/-/issues/203Forbid multiple boundary condition flags on the same cell in the flag field2023-05-17T15:22:15+02:00Philipp SuffaForbid multiple boundary condition flags on the same cell in the flag fieldIt should not be allowed to set multiple boundary condition flags on the same cell in the flag field.
This mostly happens on edges and corners of the domain boundary, even for the standard "geometry::initBoundaryHandling" function.
If t...It should not be allowed to set multiple boundary condition flags on the same cell in the flag field.
This mostly happens on edges and corners of the domain boundary, even for the standard "geometry::initBoundaryHandling" function.
If two boundary condition flags are set to the same cell on the flag field, then the order of the boundary sweeps matters and leads to different results for different orders.Philipp SuffaPhilipp Suffahttps://i10git.cs.fau.de/walberla/walberla/-/issues/202TaylorBubble does not build on Mac2023-02-08T07:45:46+01:00Dominik Thoennesdominik.thoennes@fau.deTaylorBubble does not build on MacThe TaylorBubble showcase does not build on Mac with the following error:
```
[100%] Building CXX object apps/showcases/FreeSurface/CMakeFiles/TaylorBubble.dir/TaylorBubble.cpp.o
In file included from /Users/dominikthoennes/Work/TerraNe...The TaylorBubble showcase does not build on Mac with the following error:
```
[100%] Building CXX object apps/showcases/FreeSurface/CMakeFiles/TaylorBubble.dir/TaylorBubble.cpp.o
In file included from /Users/dominikthoennes/Work/TerraNeo/walberla/src/vtk/BlockCellDataWriter.h:25,
from /Users/dominikthoennes/Work/TerraNeo/walberla/src/field/vtk/FlagFieldMapping.h:26,
from /Users/dominikthoennes/Work/TerraNeo/walberla/src/lbm/free_surface/VtkWriter.h:28,
from /Users/dominikthoennes/Work/TerraNeo/walberla/apps/showcases/FreeSurface/TaylorBubble.cpp:34:
/Users/dominikthoennes/Work/TerraNeo/walberla/src/vtk/UtilityFunctions.h: In instantiation of 'std::string walberla::vtk::typeToString() [with T = long unsigned int; std::string = std::__cxx11::basic_string<char>]':
/Users/dominikthoennes/Work/TerraNeo/walberla/src/vtk/BlockCellDataWriter.h:258:75: required from 'std::string walberla::vtk::BlockCellDataWriter<T, F_SIZE_ARG>::typeString() const [with T = long unsigned int; long unsigned int F_SIZE_ARG = 1; std::string = std::__cxx11::basic_string<char>]'
/Users/dominikthoennes/Work/TerraNeo/walberla/src/vtk/BlockCellDataWriter.h:258:16: required from here
/Users/dominikthoennes/Work/TerraNeo/walberla/src/vtk/UtilityFunctions.h:47:24: error: 'type_string' is not a member of 'walberla::vtk::VTKTrait<long unsigned int>'
47 | return VTKTrait<T>::type_string;
| ^~~~~~~~~~~
make[3]: *** [apps/showcases/FreeSurface/CMakeFiles/TaylorBubble.dir/TaylorBubble.cpp.o] Error 1
```
Apparently `uint_t` does not match with `long unsigned int`https://i10git.cs.fau.de/walberla/walberla/-/issues/201Don't create targets for tests,tutorials, benchmarks if they are disabled in ...2023-02-15T07:37:56+01:00Dominik Thoennesdominik.thoennes@fau.deDon't create targets for tests,tutorials, benchmarks if they are disabled in CMakeCurrently the make targets for tests, tutorials, benchmarks and showcases are created even if e.g. `WALBERLA_BUILD_TESTS` but they are excluded from the `all` target.
This way they can still be build when calling directly.
However it cl...Currently the make targets for tests, tutorials, benchmarks and showcases are created even if e.g. `WALBERLA_BUILD_TESTS` but they are excluded from the `all` target.
This way they can still be build when calling directly.
However it clutters the targets in e.g. an IDE.
I suggest we remove the targets entirely when they are disabled.
Opinions?https://i10git.cs.fau.de/walberla/walberla/-/issues/200GCC12: EquationSystem warning when using `DebugOptimized` and `OPTIMIZIE_FOR_...2022-12-24T14:00:29+01:00Dominik Thoennesdominik.thoennes@fau.deGCC12: EquationSystem warning when using `DebugOptimized` and `OPTIMIZIE_FOR_LOCALHOST`The EquationSystem.cpp emmits a `maybe-uninitialized` warning when build with `DebugOptimized` and `WALBERLA_OPTIMIZIE_FOR_LOCALHOST` on gcc12
```
Building CXX object src/core/CMakeFiles/core.dir/math/equation_system/EquationSystem.cpp....The EquationSystem.cpp emmits a `maybe-uninitialized` warning when build with `DebugOptimized` and `WALBERLA_OPTIMIZIE_FOR_LOCALHOST` on gcc12
```
Building CXX object src/core/CMakeFiles/core.dir/math/equation_system/EquationSystem.cpp.o
cd /build/src/core && /usr/local/bin/ccache g++ -DBOOST_ALL_NO_LIB -I/build/src -I/walberla/src -isystem /opt/boost/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/x86_64-linux-gnu/openmpi/include -isystem /opt/openmesh/include -Wall -Wconversion -Wshadow -march=native -Wfloat-equal -Wextra -pedantic -D_GLIBCXX_USE_CXX11_ABI=1 -pthread -g -O3 -std=c++17 -o CMakeFiles/core.dir/math/equation_system/EquationSystem.cpp.o -c /walberla/src/core/math/equation_system/EquationSystem.cpp
In file included from /opt/boost/include/boost/graph/depth_first_search.hpp:21,
from /opt/boost/include/boost/graph/max_cardinality_matching.hpp:21,
from /walberla/src/core/math/equation_system/EquationSystem.cpp:39:
In constructor 'boost::bgl_named_params<T, Tag, Base>::bgl_named_params(T, const Base&) [with T = boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>; Tag = boost::vertex_index_t; Base = boost::bgl_named_params<boost::detail::odd_components_counter<long unsigned int>, boost::graph_visitor_t, boost::no_property>]',
inlined from 'boost::bgl_named_params<PType, boost::vertex_index_t, boost::bgl_named_params<T, Tag, Base> > boost::bgl_named_params<T, Tag, Base>::vertex_index_map(const PType&) const [with PType = boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>; T = boost::detail::odd_components_counter<long unsigned int>; Tag = boost::graph_visitor_t; Base = boost::no_property]' at /opt/boost/include/boost/graph/named_function_params.hpp:217:5,
inlined from 'static bool boost::maximum_cardinality_matching_verifier<Graph, MateMap, VertexIndexMap>::verify_matching(const Graph&, MateMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS>; MateMap = long unsigned int*; VertexIndexMap = boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>]' at /opt/boost/include/boost/graph/max_cardinality_matching.hpp:779:61,
inlined from 'bool boost::matching(const Graph&, MateMap, VertexIndexMap) [with Graph = adjacency_list<vecS, vecS, undirectedS>; MateMap = long unsigned int*; VertexIndexMap = vec_adj_list_vertex_id_map<no_property, long unsigned int>; AugmentingPathFinder = edmonds_augmenting_path_finder; InitialMatchingFinder = extra_greedy_matching; MatchingVerifier = maximum_cardinality_matching_verifier]' at /opt/boost/include/boost/graph/max_cardinality_matching.hpp:807:79,
inlined from 'bool boost::checked_edmonds_maximum_cardinality_matching(const Graph&, MateMap, VertexIndexMap) [with Graph = adjacency_list<vecS, vecS, undirectedS>; MateMap = long unsigned int*; VertexIndexMap = vec_adj_list_vertex_id_map<no_property, long unsigned int>]' at /opt/boost/include/boost/graph/max_cardinality_matching.hpp:817:48,
inlined from 'bool boost::checked_edmonds_maximum_cardinality_matching(const Graph&, MateMap) [with Graph = adjacency_list<vecS, vecS, undirectedS>; MateMap = long unsigned int*]' at /opt/boost/include/boost/graph/max_cardinality_matching.hpp:824:56,
inlined from 'void walberla::math::EquationSystem::match()' at /walberla/src/core/math/equation_system/EquationSystem.cpp:97:4:
/opt/boost/include/boost/graph/named_function_params.hpp:192:56: warning: '*(unsigned char*)((char*)&occ + offsetof(boost::detail::odd_components_counter<long unsigned int>,boost::detail::odd_components_counter<long unsigned int>::m_parity))' may be used uninitialized [-Wmaybe-uninitialized]
192 | bgl_named_params(T v, const Base& b) : m_value(v), m_base(b) {}
| ^~~~~~~~~
/opt/boost/include/boost/graph/max_cardinality_matching.hpp: In member function 'void walberla::math::EquationSystem::match()':
/opt/boost/include/boost/graph/max_cardinality_matching.hpp:778:52: note: '*(unsigned char*)((char*)&occ + offsetof(boost::detail::odd_components_counter<long unsigned int>,boost::detail::odd_components_counter<long unsigned int>::m_parity))' was declared here
778 | detail::odd_components_counter< v_size_t > occ(num_odd_components);
|
```https://i10git.cs.fau.de/walberla/walberla/-/issues/199Make CMake and CodeGen simpler2022-11-29T13:03:44+01:00Markus HolzerMake CMake and CodeGen simplerAt the moment all generated files, that come out of the CodeGen script need to be manually stated under `OUT_FILES` in the `waLBerla_generate_target_from_python`. Example:
https://i10git.cs.fau.de/walberla/walberla/-/blob/master/apps/ben...At the moment all generated files, that come out of the CodeGen script need to be manually stated under `OUT_FILES` in the `waLBerla_generate_target_from_python`. Example:
https://i10git.cs.fau.de/walberla/walberla/-/blob/master/apps/benchmarks/FlowAroundSphereCodeGen/CMakeLists.txt
This has some disadvantages:
1. It is always a bit clunky because as a user you first provide the names of the `OUT_FILES` as strings to the generation function and then one needs to copy all these names in the CMake file again.
2. It is error-prone in a few fashions. The biggest issue is the correct file ending for GPU support. This was partially solved in !518, however still one needs to think about whether a file is only generated for CPU or can vary depending on the CMake configuration. Second, some generation functions like `generate_info_header` only produce a header file. This user must know this to write a correct CMake file first try ...
3. A third big problem is, that every generation function can only produce a single file. Otherwise, it would be impossible for a user to know which files will come out in the back. Thus this system lacks flexibility as wellMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/198Walberla with Openlb and Cuda Walberla/walberlav6.1/apps/tutorials/lbm/03_LBL...2023-01-27T11:39:21+01:00mosembWalberla with Openlb and Cuda Walberla/walberlav6.1/apps/tutorials/lbm/03_LBLidDrivenCavity.cppGood afternoon y'all. So i am wondering how can i easily convert the Walberla/walberlav6.1/apps/tutorials/lbm/03_LBLidDrivenCavity.cpp application so support both Openmp and Cuda. I have played around with the same application trying to ...Good afternoon y'all. So i am wondering how can i easily convert the Walberla/walberlav6.1/apps/tutorials/lbm/03_LBLidDrivenCavity.cpp application so support both Openmp and Cuda. I have played around with the same application trying to use more threads in the enviroment with the use of export OMP_NUM_THREADS = [number of threads] seems that i get worse performance if the number of threads is more than one. So my question is how can i impliment threading in walberla? My goal is to run walberla in HYBRID (Openmp with MPI) mode for the lid-driven app and with CUDA. I have seen this function for Openmp, do i think around the same lines? In normal Openmp pragma omp{} starts the parallel section what would be the equivalent in Walberla? | #define WALBERLA_FOR_ALL_CELLS_XYZ WALBERLA_FOR_ALL_CELLS_XYZ_OMP( field, omp parallel for schedule(static), CODE )
And for cuda do i have to write something new completely?Philipp SuffaPhilipp Suffa