Units in LBM

Hi there,
I have been struggling to find out how to choose a proper value for dx, dt and e=dx/dt in LBM. I have read all the forum threads here and also the white paper by Latt. However, I still have problem how to figure out how these three should be selected to ensure the microscopic model is a representative of the prototype. Do they depend on each other, or each of them are calculated independently?

In all LBM literature I have found lattice velocity mentioned as e(or c)=dx/dt; however in Latt’s article a reference u0,lb=dt/dx is defined which I am not sure what does it mean. I have seen in the literature that people refer to LBMs in which e=dx/dt= 300, 500 or even more.

In the algorithm to solve the equilibrium functions, which c should be used (dx/dt or dt/dx)? and what is the simple, clear steps to approach a LBM problem?

Many thanks

I think you are mixing up a few variables here and also what system of units you are using (pysical units or lattice units).

LBM usually thinks in terms of lattice units, i.e. the distance between to cells is dx_lb = 1. Likewise for time, our dt_lb is 1. The physical distance between two cells and the physical time step is normalized. This doesn’t mean that the (physical) dx_p and dt_p don’t matter. The normalization procedure of these two yields different values for visosity, gravity, etc. in lattice units. More concretely, if we have dx_p = 0.04 meters and dt_p = 0.01 seconds and we transfer these to lattice units (i.e. normalize them), we accordingly have to use these dx_p and dt_p to obtain values for viscosity, gravity, etc. in lattice units. So you see, if we change dx_p and dt_p, our values for viscosity, gravity, etc. change accordingly. Check the following thread where an example is given how to transfer quantities in physical units to qunatities in lattice units: http://www.lbmethod.org/forum/read.php?3,3562

If you understand the above, you also understand that the c = dx_lb / dt_lb is also 1 and divisions by this values is therefore often omitted from equations. I have no idea why people get a c of 300 and 500, this can only happen if dx_lb and dt_lb is not 1, which again is not recommended because that makes things very obfuscated in LBM.

As for dx_p and dt_p being related. In principle you can choose these two values as you want. However, for stability and accuracy reasons it might be better to choose them such that dt_p ~ dx_p^2 holds.

Thank you very much for your response, Bart.

I understand that in the microscopic world of lattices, we assume that dx_lb=1 and dt_lb=1, and therefore c=1. This c does not have any units but the c (or e) of 500 or even 800 that I have seen in the literature has real units (m/s).

Please correct me if I am wrong: From what you have written, I conclude that the value of c that appears in the BGK equilibrium functions always takes the value of c=1 and therefore can be cancelled out.

If that is the case, what is that speed with real units that people refer to and appears to affect the convergence and stability of the solution?

There are some recent literature that suggest a stable range for c to make the solution converge.

I am totally confused!

Heaps of thanks :slight_smile:

Yes. Unless an author explicitly states that he doesn’t use normalized dx_lb and dt_lb you may safely assume that c = 1.

This seems an odd statement, since I can assure you that the simulations I performed with c = 1 do converge. Please provide a reference.

I don’t know who “these people” are and what they exactly wrote, so I can’t really comment on that. I think you are mixing up the values c (which is actually not such an important variable if you keep dx_lb and dt_lb equal to 1) and the cell velocity u. Reading through LBM literature you must have come across the following two formulas to obtain the density rho of a cell and the velocity u of a cell:
rho = sum_i(f_i)
u = 1/rho * sum_i(f_i)

where f_i denotes the distribution function of a cell in the i-th direction. The velocity of a cell u may not become very high, otherwise instability will occur.

I don’t know how much literature you have read before posting, but I think you may want to read a bit more about the basics of LBM. I found the following links explain the subject quite well with some good illustrations:
http://graphics.ethz.ch/~thuereyn/download/nthuerey_070313_phdthesis.pdf (first three chapters)


Thanks for your detailed comments.

I am working on LBM applications on shallow water flows and in almost all the published literature (papers or books) the author(s) refer to a so called “lattice speed”, which is expressed in m/sec. For example the book Lattice Boltzmann Methods for Shallow Water Flows by Zhou, he provides examples with e=200 m/s and e=800 m/s. Also here in this forum, Timm refers to e=dx/dt=500 m/s here.

Based on the fact that in lattice units c (or e)=1, I am thinking that perhaps these high c values should be interpreted as lattice speed in real physical units, is this possible?

At the moment I have a LBGK FORTRAN code (D2Q9 scheme) with equilibrium functions that have “c” in them. Now based on your comments I know that I should use e=1 in those (or cancel them). but since we have terms with “dt” and “c” in the collision-streaming step I have to know what values should I use for “c” and “dt”.

Everything in this code in expressed in real units, including g=9.81 m/s² which appears in the external force and equilibrium functions. In other words, I do not do any post-processing to convert the results from lattice units to physical units. In my code the u = 1/rho * sum_i(f_i) that you have referred to in your post, means water depth with real units.

My code currently works well and yields correct results if I set e=10 m/s (the value of 10 is used through the code, including calculation of equilibrium functions and collision-streaming step) and dt=0.01 s; but I have found these values by trial and error and I have no idea what is the correct basis for choosing them. If you wish, I can send over my code to you maybe you can find a clue.

I have followed all the steps recommended by people in this forum to maintain hydraulic similitude between physical and lattice models (using the same Reynolds numbers), but the code crashes for all other values of e and dt, including c=1.

I have already had a good understanding of LBM and read Jonas Latt’s article on units and other threads in this forum on units, but still am confused. If I am not using the correct values of e and dt, or if my model is substantially wrong how is that I am getting the right answer???


I’m sorry I thought we were talking about lattice units. Indeed, in the case of physical units c_p = dx_p / dt_p can have different values, depending on how you choose dx_p and dt_p.

Yes high (physical) c means high lattice velocity.

In an actual LBM simualtion we use lattice units, not physical units, so in that case we have dx_lb and dt_lb, which are equal to 1, so c = 1. So yes, the c cancels out in the equilibrium equation. And in the streaming equation we have dx_lb=1 and dt_lb=1 and therfore c=1, so this means that in one dt_lb (i.e. one time step) we travel one dx_lb (i.e. one cell). So this means the distribution functions travel along the velocity vectors to their neighboring cells in one time step. (see the beauty of having dx_lb=1 and dt_lb=1)

Same as I mentioned in the above, in an actual LBM simulation we use lattice units, so you should convert every quantity defined in physical units to lattice units, otherwise you will get errorneous results. I don’t know why u = 1/rho * sum_i(f_i) means water depth in your code, but I also have no experience with shallow water equations, for conventional LBM it represents the cell velocity,

In general, most people don’t set the lattice velocity directly, but set the physical dx_p and dt_p and consequently use them to convert the viscosity, gravity, etc. from physical units to lattice units. As I stated in a previous post, it is best to maintian the relation dt_p ~ dx_p^2 for stability and accuracy reasons, you can find out more about that in the units document of Jonas Latt. So start with a low value, e.g. dt_p = 10^-6 and dx_p = 10^-3 and also do not choose your viscosity very low, because this will yield a low relaxation time and that can also cause instability.

I think you are not getting the right answer because you are still using physical units in your simulation somewhere and did not convert them to lattice units. Instability can also occur if you choose your (physical) dx_p or dt_p too large or your relaxation time too low. If you haven’t tried yet, you could first simulate without gravity and see if nothing odd happens with your simulation. If that works, incorporate gravity and test again.


First of all, I should thank you for the time you spend answering my questions. They are making things crystal clear to me.
Based on what you are saying, I need to convert all physical parameters (gravity, flow depth, velocities, etc.) to lattice units, then conduct the simulation in lattice units (with c=1, dt_lb=1, dx_lb=1), and then do some post processing; which is converting the results from lattice units to real physical units. Is my understanding right?

If this is the case, then I have to find out how to express every physical parameter in lattice units.

Again, I really appreciate your help.

[quote=mathloverboy]First of all, I should thank you for the time you spend answering my questions. They are making things crystal clear to me.
Based on what you are saying, I need to convert all physical parameters (gravity, flow depth, velocities, etc.) to lattice units, then conduct the simulation in lattice units (with c=1, dt_lb=1, dx_lb=1), and then do some post processing; which is converting the results from lattice units to real physical units. Is my understanding right?[/quote]
You get the idea now. You only need quantities in physical units at the initialization to convert all variables to lattice units and at the end of your simualtion to convert relevant values back to physical units.

There are several threads on this forum that discuss that, you could for example check out the link I gave in my second post in this thread.

Excellent! Thank you very much, Bart!