jviquerat / lbm Goto Github PK

@jviquerat Regarding the boundary conditions. What I did differently as compared to your code is:

• I applied half-way bounce-back (and not Zou/He) to the top and bottom no-slip wall as well as to the corners. What I did was perform a streaming step for all cells, then reverse all populations in the boundary and stream them back to where they came from. This results is an inversion of the first fluid layer without the need for a structure (such as your boundary array) that keeps track of the fluid neighbours of an obstacle. I am not sure if your implementation that copies the non-equilibrium distribution from the neighbouring wall and performs non-equilibrium bounce-back indeed gives the correct velocity. The inward corners are sort of under-constrained singularities in LBM.
• Then I applied the Zou/He boundaries only to the pixels 1:(ly-1) (excluding the corners). I used the momentum expression for the non-equilibrium part instead of the non-equilibrium part directly. I am still not sure if your approach gives you the correct results.Thus, I would actually prefer my version.

Hi,
Thank you for this great LBM file.
I wish to ask is there anyway to couple LBM with DEM based software like PFC based on Python?

Thank you in advance

Hi @2b-t,

Just to let you know that I spent a bit more time on adding Numba to the code this morning. Eventually managed to cut execution time by 50%, however the code is ugly (see branch numba).
Thanks again for all the help you provided ;) I think I will use the code as is for now (started using it for optimization purposes actually), and at some point I will rewrite it in cpp to get proper performance.

hi，I‘m a beginner of LBM，i want to ask u a basic question, if i want to change the type of the obstacle how can i define my program, after trying several times,it is still something wrong in shape_type.

Hi Jonathan,

I tried to repeat the benchmark calculations with your code and got different values for the drag and lift coefficients.
E.g. for Re = 100 and L_lbm=ny=100 I tried 3 different velocities (original value 0.05; 0.02 and 0.007), i.e. different relaxation rates. The values for the average drag coefficient differ only by around 1% from the 3.5409 that you provide in the README file. However, the average lift coefficient is always around 0.11, falling below the specified value by a factor of 10.
Did you perform these calculations with other parameters than in the uploaded code ('magic parameter' etc.)?

I would also appreciate a comment on the calculation of the drag and lift coefficients. According to your code, they are calculated based on first-order moments of the sum of collision and total distribution functions. According to several sources, it should be second-order moments of the non-equilibrium part of the distribution function (https://journals.aps.org/pre/abstract/10.1103/PhysRevE.79.046704).

Thank you in advance for your reply!
Best,
Yevgeniy

Hi @2b-t,

A small update on IBB, using the "best" interpolation proposed by Bouzidi et. al.
For now I am considering a square in a channel at Re=20. The channel is larger than my previous case, as I was wondering wether the large gradients above and below the obstacle could be a problem for the LB to resolve. I computed a reference value for drag and lift using a very refined Fenics computation.
Things seem a bit better with IBB, although it makes no wonder, at least in this case. It could be due to this specific case, as the measured lift is very low.

On the drag, IBB is barely better than BB (it's a zoom on the end of the graph):

On the lift, we can see a difference, as BB lift does not improve when refining. Still, it seems hard to explain the differences between BB and IBB for ny=100.

The domain is voluntarily short to limit computational time, but I did the same for the Fenics computation.

Hi again @2b-t,

Something I noticed regarding the drag-lift computation, is that my problem seems to be (partially) related to the discretization. Let's consider the same configuration for a cylinder and a square of same lateral size :

Disregarding the normalization/scaling, which is probably wrong :
For the cylinder, final drag and lift = 12.692730642588893 -133.4031935237444
For the square, final drag and lift = 15.570420109494938 -0.06360486760453934

So the absence of symmetry in the application of the MEM yields large errors here, especially in the lift. If I refine the cylinder, I get significant differences in the final drag and lift. There must be a blatant coding mistake somewhere, but I can't locate it.

In line 209
rho[:,0] = (g[0,:,0] + g[1,:,0] + g[2,:,0] +

This seems to be
rho[:,ly] = (g[0,:,0] + g[1,:,0] + g[2,:,0] +