Adrian
Forum Replies Created
-
Posts
-
If you want to run it without modification you will need to compile it for CPU (OpenMP and MPI are of course still supported).
You are also welcome to adapt the post processors to the operator style, see e.g. the user guide FAQ section for an introduction to this new style introduced in OpenLB 1.5.
Some post processors used in this example case are not yet adapted to the new GPU-supporting style. You can see a list of all fully supported examples in the release notes.
These are just cells in the overlap layer surrounding each block lattice in all direction, i.e. also the very outer boundary. You can safely ignore them.
Ok – while the parameters and model selection look ok I can still only guess without seeing the actual case and / or a more specific question.
e.g. your reference to “[…] at some points at the inlet near the walls” leads me to suspect that there is a problem in your geometry setup / discretization. It could also be caused by a mismatch between material geometry and your boundary setup. Or there may be an issue with how the framework is used (e.g. dynamics parameters not defined correctly, or…). Or it could be something else entirely.
Can you share any details of your case setup? Without this it could be anything.
The fluid parameters in Venturi 3D are just as a model example and are not supposed to model an actual real world fluid.
This is most likely caused by the outflow layer being non-axis aligned and “too thin”, causing the staircase approximation to only be realized partially. The geometry should be better if you increase the cylinder length (which you already tried) so the issue is probably that the wall of material 2 that the call renames is also incomplete.
However, depending on the boundary condition (i.e. if you use the default pressure boundary) you will need to rotate the geometry s.t. the outlet is axis aligned anyway as pressure boundaries are tricky in such situations (one common approach is to flip velocity and pressure boundaries s.t. there is only a single pressure inlet and multiple (not necessarily axis-aligned) velocity outlets.
Most parameters are defined at the top of the file, e.g. the resolution N is defined in line 97.
In any case you can change all parameters by modifying the source code, although you may want to read some parameters from a file / CLI argument to avoid recompilation. I suggest you check out our user guide for a basic introduction into OpenLB, this will help in adapting existing examples including tgv3d.
How is your 2D geometry defined? One way I have seen applied is to import pixel image formats to set up the geometry. You could also evaluate a STL only on a 2D plane.
This depends on what you mean by “obtained a 2D porous media model using Matlab”. i.e. this geometry will be described by some kind of data structure in matlab that you need to output in some format that you can then read into OpenLB. e.g. one possibility would be to export it as a 2D VTI image.
Another question is what LB model you want to use to represent this geometry in the simulation.
The convergence criterion of the laminar version quite likely is not what you want for a turbulent setup. You need to decide yourself which criteria is suitable for your specific situation. I.e. you need to actually decide on your exact simulation model before trying to adapt any code.
Solution for what? Did you actually change the physical parameters or just the collision model?
I repeat: The error here is the difference between simulation and expected reference solution, not a program error. If you mean the gnuplot warning: just install gnuplot if you want to directly generate result plots for your simulation.
What do you mean by “required output”? Going by your first message I guess you just want to change the physical parameters which you can achieve by changing the parameters given to the unit converter.
This is not an error – the same message (with different results) is also printed for the unmodified lid driven cavity case. As the description suggests it is not a program error but the numerical error between simulation and reference solution.
The problem is that your custom field PREV_PHI is not a member of DESCRIPTOR but a separate type. Simply amend your field get/set functions to use it without the DESCRIPTOR:: prefix.
Yes, this is possible and
particles::creators::addResolvedArbitraryShape3Dis the correct function for this. (One restriction that I am aware of is that the particles currently must be concave if you want to use the contact model)