Boundary conditions about lbm HOT 9 CLOSED

Well, regarding the second point, although I cannot explain it, it makes a significant difference to write it your way (no blow-up with BGK).
Now I have to rewrite all my Zou-He BC ! :p

from lbm.

And unsurprisingly, it has a major impact on the computed drag :

from lbm.

@2b-t

• I tried to follow the ideas of Kruger (p.201, section 5.3.5.4 and then for corners p.204 and further), but I will try to go through it again. I just went for Zou-He after reading all the accuracy studies he made about bounce-back, but that might be irrelevant
• Regarding the fact that I use the equilibrium distributions and not the macroscopic fields, to me it should make no difference, as I compute macro/equilibrium/collisions/stream/B.C. The macroscopic fields are just as up-to-date as the equilibrium fields are. Does that make sense to you ?

from lbm.

Yeah, but Krueger calculates it from velocities again and not with f^{(eq)} such as you did/do. As you can see from 5.56 (page 204) if the walls are at rest this is basically just bounce-back, so no need to put more effort. The other populations are buried links that do not contaminate the solution as they never enter the fluid (their impact after collision is overwritten with the corner boundary condition), you can set them to whatever (see note under 5.58 on page 205). Corner treatment is only important if two velocity or pressure boundaries meet to form an edge.

from lbm.

As I said I already believed it might have an impact. Mainly because I had never seen it that way (and I went through several source codes and dozens of LBM papers, in particular the old ones use it a lot) and additionally as f^{(eq)} has changed due to streaming: Zou/He does not replace the populations that exit the boundary, it replaces the one that enter them. The populations collide and stream anyways! This means you setting them at the end of a time step is just equal to setting them at the beginning of every time step (apart from the first time step). This means the f^{(eq)} you use is one time step old!
Furthermore I have checked your boundaries and the rest of your code already. This is the only part that is mathematically not identical to my implementation. Thus I assumed it was the reason for the artifacts and the crash with BGK. TRT is better at avoiding negative populations due to the coupling of directions but BGK crashes easily if you impose a negative velocity somewhere, it is a lot less stable!

from lbm.

The disadvantage of Zou/He is that it is not straight forward to extend to 3D. It is a wet node not a linked based technique. If you assume further symmetries you can find the Hecht/Harting boundary conditions you can find in my thesis but both of them are not very robust and weirdly enough if you use them with a turbulence model they do not stay stable at all but instead trigger artifacts. I assume the non-equilibrium bounce-back does not hold for a flow with turbulence model anymore. In my opinion the most physical ones are the ones by Latt as they they try to impose f^{(neq)} by using f^{(1)} from the Chapman Enskog expansion. I am not sure if my thesis contains a note on how to derive them. Nonetheless they are not stable with a turbulence model either. For the best stability (even with a turbulence model) use interpolation boundaries that copy f^{(neq)} from the neighbouring fluid cell and only impose f^{(eq)} such as Guo's interpolation boundaries. I have solved turbulent flows in 3D wih it already such as in this video: https://www.dropbox.com/s/fry6d1k6bi55xbt/2%20Spheres%20Turbulent%20Cross-Section%20%28BGK-LES%20Re_in%203750%20Sc%201%20Sc_t%200.7%20Concentration%29.avi?dl=0

from lbm.

For now there is no planned extension to 3D :)
As soon as I have a working drag computation for moderate Reynolds flows (100-500 max) around shapes I have the tool I need (although I might spend a few more days trying to speed it up).
If accuracy is reasonable, I don't need much more ^^

I have just corrected all the Zou-He b.c., I'm running a few tests now, will let you know in the afternoon :)

from lbm.

The video looks really nice !

from lbm.

I think we finally are getting to the point where it works reliably! Virtual high five!
Lucky you! :) 3D is a pain in the ass to debug because it takes so long to simulate.
It depends on how the Reynolds number is defined. I found simulations with a Reynolds number of up to 300 in terms of the cylinder diameter to work fine with TRT if the diameter is resolved by around 20 nodes. With BGK the simulation crashes sooner. In case the simulation is not stable you can either increase the resolution and thus the computational burden or include Guo's boundaries as previously mentioned. I have a section on it in my thesis as well (including stability). Higher flows than Re > 300 in general start to exhibit 3D behaviour with three-dimensional turbulent structures in the wake. Thus, a lot of people argue that 2D simulations are of limited benefit. Accuracy should be fine if you wait for the unphysical pressure oscillations to even out.
Regarding speed I have some figures on performance parallel scaling behaviour in my thesis as well (page 84) onwards. What my final 3D version was capable of after adapting the AA-pattern can be found in this document on my dropbox: https://www.dropbox.com/s/ge4v9pilbuke8jy/Short%20description.pdf?dl=0 I found though the AA-pattern though to not be beneficial for 2D! You can use these values as what should be theoretically possible in C++. If you get close to 1/3 of the performance with Python I would call it a day.

Thanks! The video is basically a cross-section of 3D gaseous turbulent diffusion of a tracer in porous media. So two lattices, one for fluid flow, one for diffusion, coupled, both with a Smagorinsky turbulence model.

from lbm.