Adrian
Forum Replies Created
-
Posts
-
This is unusual. Which is the exact command you use to run the nozzle case? Did you increase the frequency of VTK output compared to the default?
Are gou using single or double precision for the value type?The low average leads me to believe that there is some issue with the VTK output (e.g. is not performed asynchronously or too often to hide it)
The nozzle case uses a computationally complex turbulent inlet condition s.t. heterogeneous CPU-GPU use can provide an advantage to GPU only.
I assume that you observe this only for the nozzle case and the cavity benchmark behaves as one would expect?
pi[2] is the xz component of the strain rate tensor in 3D. In 2D pi[2] is the yy component.
For a duct another case, e.g.
turbulence/nozzle3dmight be a better starting point. For the channel case the first step will be to remove the periodicity towards the sides of the domain (see the call toCuboidGeometry::setPeriodicityin line 413) and set other boundary conditions on the resulting walls.
If you describe your desired setup in more detail we will be able to provide better guidance.Good to hear! This also explains my confusion, I did not have that detail of the FS code in my mind. We should change the naming, it is quite confusing in this case.
What do you mean by “their tasks”? What is meant by a post processor in OpenLB is a struct that defines its application scope and priority together with a
applytemplate method that implements the actual computations. If some model such as free surface splits its algorithm into multiple tasks these tasks are realized as individual post processor assigned to one or more stages and priorities.The order in which post processors are added (meaning the calls to
addPostProcessor) does not matter for the execution. The execution is ordered first by stage and then by priority. Post processors (or “tasks”) that share the same stage and priority are executed in parallel, platform permitting.On the post processor scheduling: Post processor don’t schedule themselves, i.e. they are not tied to any stage. The stage is assigned by the call to
SuperLattice::addPostProcessor(the default beingPostStream). You can also (in principle) assign the same post processor to multiple stages. The priority however is declared by the post processor structs (a pragmatic choice, I would prefer this to also be handled by the assignment call but for the actual implementations the current approach seemed better).The core is allowed to execute post processor assigned to the same stage and priority in parallel. Whether this actually happens depends on the platform (e.g. on CPU without OpenMP they will be executed in some sequence while on CPU OpenMP / GPU CUDA they will be scheduled in parallel to some degree).
For your example: Each stage is executed when it is called, inside each stage the priorities are executed in sequence, inside each priority everything is parallel (potentially).
Ok, can you point out the part that is declared twice? I don’t really want to go through the entire listing you posted line by line 🙂
In general you do not need to follow the structure of the existing setter function for the modification you described. Boundary conditions in OpenLB are the dynamics and post processors at the boundary cells, the setter functions just “set them up”. If I understand you goal correctly, having separate setters per model seems to be a better approach then adding more complexity to the existing setter. I may be able to give more concrete recommendations if you describe in more detail what you want to do.
By appears twice you mean the separation of class / method declarations and definitions? This is what the h/hh split commonly does. The *.h file declares a class and its methods while the *.hh file actually implements it. This is a common approach in C++ – due to the growing templatization in OpenLB this becomes less necessary / helpful but it is still followed in large parts of the codebase.
I think it would be helpful for you to first learn some C++ basics before trying to use OpenLB (this is not meant to discourage you, learning C++ and OpenLB details at the same time would be a challenge for anyone).
What do you mean? Which c1 and c2? What difficulties? Please show your work or actually try to explain your problem, otherwise one can not really help you.
Sorry, but it is basically impossible to tell you anything without you sharing at least the error message and what you changed.
Good to hear!
One nice way is to use volume rendering in Paraview. Please note that this is not in any way OpenLB specific, we just export VTK that can then be post processed in e.g. Paraview the same way as an OpenFOAM case.
On the performance question: In that case you simulated without any parallelization (or even vectorization for the single process). For your hardware OpenMP will likely perform best but you can also use MPI. There is documentatiom on this on the user guide and also in the comments of the config.mk file where you can adjust the parallelization modes.
What visualization mode / filter do you use in Paraview for the 3D case? Depending on the option the interior of the domain will be fully hidden by the boundaries by default, making it look as if nothing is changing. Did you try e.g. slicing the domain?
How did you execute the case? 3 hours seems quite slow.
We plan to release version 1.8 sometime in April, definitely before the spring school.
Yes, in principle this should be possible (I experimented with this before, if I remember right there were only some small issues due to the value types being used in vectors). However, this approach is not really intended, I recommend using individual fields (and e.g. use some additional functions to operate on them if they belong together).
Yes, it seems so.