Adrian
Forum Replies Created
-
Posts
-
Can you share your modifications of the case so we can reproduce your issue?
1) You can ignore the geometry error here. This is a remnant of the current geometry validity conventions (e.g. that a material 0 (inactive) cell must not directly border a fluid (material 1) cell) only holding for uniform grids. You can remove the check method until we have a resolution-transparent geometry model in a future release, if this message bothers you.
The current release of the refinement module is a prototype that requires deep OpenLB knowledge to transfer to other cases. We are working on a user-friendly way to generate the refined meshes but this will take time.
2) Validation is in progress. In any case, grid refinement should always be evaluated for the specific application and LB models as it is a very active and unsettled topic. E.g. any refinement introduces an additional error source that can only be ignored after careful consideration and numerical tests.
3) This is a good example for the difficulty of refinement in LBM: It depends. A simple approach is to only couple bulk cells (as refinement schemes are commonly evaluated only in the bulk). For 3D Schäfer-Turek (cylinder3d), not coupling the wall cells suffices in my experience.
4) It should if the non-equilibrium is in fact obtained as the difference between current populations and their second-order equilibrium. If this doesn’t hold the coupling needs to be adapted.
Please also note that the public version implements a simplified version of the vertex-centered scheme by Lagrava (it uses very simplified spatial interpolations). A full version as well as support for cell-centered couplings are in the works.
The work on grid refinement is currently limited mostly by the number of developers working on this, if you are interested I’d be happy for any help.
Of course AMD is supported. The config folder just privides examples. The default MPI config using OpenMPI will work on AMD without issues. You can follow the comments in the default config.mk and our user guide.
As you did not provide any information on your modifications it could of course be anything.
As you state yourself that the original version works on GPU, it is obvious that you broke something with your changes.
These are just warnings that the VTI file doesn’t explicitly give the number of components and a fallback to a single component is used. Just to confirm I tested myself using the instructions in the file and the simulation proceeds as expected.
Keep in mind that this is a complex multi-phase application using many additional fields so the performance is lower than usual. e.g. on my laptop using 4 cores it yields a throughput of ~10 MLUPs. I suggest to increase both the
vtkIterandstatItervalues to monitor the progress on your system.Currently there is no collision modifier for sourced ADE implemented in the code (which would make this a one-line change).
How we commonly do this is via a custom collision
SourcedAdvectionDiffusionBGKdynamics(seesrc/dynamics/advectionDiffusionDynamics.h). So you can either copy this dynamics and adapt to your needs or you can implement a sourced collision modifier that you can combined with theParameterFromCell(if so I can help you by giving the first steps).The STL file for the centrifugal pump case is indeed missing from the release tarball. For the moment you can download it on Gitlab.
As for the nozzle case: This case doesn’t use a STL at all so it would be very weird for it to throw that error. Did you mean to refer to some other example?
Ok, so I assume you can not compile any case currently, not just the refinement ones?
I just re-checked and due to C++20 support restrictions 1.8 needs at least CUDA 12.4. However, for 12.2 I still get different errors than you. I suggest you update to 12.4 and try first with the
config/gpu_only.mk.This is most likely a configuration or compiler problem on your system (the error is not in any way related to the grid refinement example and example compilation is validated for many different configurations in our CI).
Can you share your configuration and environment details?
Ok, so do you already have an exact idea of which actuator disk model you want to apply?
Without knowing much about this approach I guess it will boil down to updating the per-cell forces for the cells in the actuator disk domain every time step depending on the surrounding flow / model parameters. If so, a good way of implementing such operations in OpenLB is to write a “post processor” and assigning it to the respective cells for execution at a sensible step of the LB algorithm (commonly the post-stream “stage”). Our user guide provides an introduction on how to write such a post processor.
OpenLB offers a set of flexible primitives for implementing any LBM scheme. Currently I am not aware of any public implementation of an actuator disk model but I can guarantee that it is possible to implement this. If you tell me what exactly you want to do, I will be able to point you at a good direction.
Yes, we do this all the time. If you tell me details about your setup and environment I will be able to provide guidance.
Which voxelization do you mean exactly?
If you refer to the material geometry / indicators in general: They are only evaluated on CPU in any case. Are you sure that the GPU usage is the problem and not e.g. difference in domain decomposition?
Looks nice! Do you want to add this to OpenLB? If so we are always interested in new contributors.
Happy to hear that it performes better now.
However, this is very unlikely as the actual reason. The features array is not involved in any way for this.
Cab you post your two configs?