Combine Immerse Moving Boundary with Multi-Relaxation time

Hello everyone;
I am simulation particle behavior under increasing the hydraulic pressure between inlet and outlet. However, to get the small delta LB Rho between inlet and outlet, my tau is very small. So I am trying to use MRT for my model. I have read a several articles but I am still unclear. The following is the equation for IMB:

So to combine with MRT, can I just change the -1/tau to MSM-1 and keep the hold equation ?
Thank you

Hi Michelle,

usually with IBM people mean the immersed bounday method that works in the same way for all collision model. IBM basically computes a macroscopic force to apply to the fluid.
Now the formula you posted seems to be more a Partially Saturated Method PSM. The standard method was presented in the BGK case, I don’t know the extension for the MRT, but if you do a bibliographic research I would be interested to know. I think that as a first step an extension to the TRT is more straight forward…

Cheers,

mars

Hi Mars;
Thank you for replying. I considered to used TRT as it is more easier. However, my problem is that my relaxation is small (0.501) , to make the model stable (tau_s-0.5) * (tau_a-0.5) = 1/4, which leads to a very high value of tau_a = 125. Some of the articles that I read, they said tau_a should be less than two.
What do you think ?
Thank you
Ragards,
Michelle

Hi Michelle,
I think that to have accurate results both tau should stay on the order of a unit. Beside this I think it could be stable anyway even with higher number for tau_a. Can you post the link to the reference you are mentioning?

But I think the main point here is: why do you want to have such a low tau_s?
can you explain better the following sentence?

Hi Mars;
Thank you for replying, according to my unit conversion from the physical unit to LB unit.
delta LB Rho = delta P_lb / cs_lb^2 =3 x deltaP_p x dt_p^2/dx_p^2/rho_p (1)

delta LB Rho should not be larger than 0.2.
My deltaP_p is 350 Pa, rho_p is 1.2 kg/m^3, dx_p = 0.024 (m) /100= 0.00024 m
If I want my delta LB Rho < 0.2 => dt_p < 3.6E-6
Tau = 3 x dt_p x nu_p/dx_p^2+0.5
nu_p is 1.5E-5 m^2/s , dt_p = 3.6E-6 dx_p = 0.00024
=> tau = 0.5028

Hi Mars;

This is one of the papers that I have read : http://www.fast.u-psud.fr/~talon/Publications/PDF/talon12b.pdf . In section 2.1, the author mentioned

image

Thank you for your time and kindness.

Hi Michelle,

I am not sure, but I think that here

you are constraining a non-necessary parameter…Let me explain. In LBM pressure and density are not independent, so if you try to inject both information in the non-dimensional representation is like you are constraining an additional parameter should be free: timestep. I would try to re-parametrize the problem using non-dimensional numbers depending on the physical problem.
For example: fix the friction number of the domain
image
where everything is in adimensional units. Fixed the max \delta\rho you can play with the aspect ratio of your domain to get the same physical friction parameter without modifying \nu_lb i.e. \tau_lb. Then you can do the same with the particles, like fixing St number and Re_particle. I’m still not sure of how the pressure should influence the particle dynamics in your case. I think it influences it in an indirect way changing the fluid flow…

Hope this helps,

mars

1 Like

Hi Mars;
Thank you for replying my question. I tried your suggestion but I did not get it. In the equation that you provided, D, L, density, viscosity and Cs (without modifying nu_lb => dt_p is constant) are constant. So the only variable is delta rho ? Later on, I need to obtain the physical value of pressure, my pressure is very small.
I am not sure what you mean " play with the aspect ratio of your domain" ?
My numerical model is about capturing the change in discharge velocity at the outlet under increasing the pressure difference between inlet and outlet. When I increase my pressure difference => my fluid velocity increase, and until it reaches the critical level, the particles move upward.

Hi Michelle,

what I mean is: if you want to simulate exactly your physical model in the simulation, then you are screwed and you are doomed to use the very small timestep of your analysis…but if you define your physical problem computing a non-dimensional parameter and then you scale the problem for your computational model matching the non-dimensional parameter, but not strictly all the other parameters, then you can freely choose the timestep.

For example with the parameter f above mentioned (but you should find the best non dimensional parameter for your case):
physical model -> compute f_phys
f_phys = f_model
f_model = f(model_parameters,timestep)
=> choose timestep and then set other model_parameters in order to get the right f_model=f_phys

Is it more clear what I mean?

Francesco

1 Like

Hi Francesco;
No word can express my gratitude. Thank you for your help. I kind of get your idea. I just want to confirm, the model parameters, should it be in LB unit, i.e in the friction equation, the kinematic viscosity should change to nu_lb, and density of fluid become 1, and the length and diameter convert to LB as well ?
Or did you mean I should scale the size of my model, i.e change the diameter and length ?
I am sorry if I aksed a dump question as I am not good at the unit conversion in LBM.
Thank you

In practice yes, lattice units, because in lu you build your siumulation. And so rho_0=1, L and D as well in lattice units. The physical meaning is guaranteed by the fact that the combination of parameters give you the right non dimensional number. But beware: you must be sure to respect all the constraints all non dimensional number that are important to describe your problem. So focus on thinking about the right non dimensional numbers.
I really hope this will be helpful,

mars

1 Like

In other words…physical model (physical units) and numerical model (lu) are coupled between themselves only by means of “same non dimensional number of interest”. In this way in the numerical model side you should be able to freely choose the time step in the limit of stability and accuracy.

Hi Mars;
Your suggestions have helped me a lot. However, there are some problems pop up during I do the conversion. When I tried to convert the pressure in LU (deltaRho_lb* Cs_lb^2) to the physical unit, it is smaller than the physical pressure that I used to calculate the f_phys. I think it is because I scale up my numerical model. So does it mean by doing this way, I need to do some extra steps if I want to convert from LU to the physical unit?
I did a hand calculation on what you suggested to me. However, the time step in lb unit is quite small and as I do not have much experience in LBM, I am not sure if it is applicable. I did the calculation for the f_phys = 1.5E11. And in my numerical model, D, L, rho are unchanged. And I used 0.8 for my relaxation time => nu_lb = 0.1 and I choose dx_lb = 0.01=> my dt_lb is 4.7E-8 , and my velocity (dx_lb/dt_lb) in lu is 212123.0344. Do you think my velocity in lu is too large and dt_lb is too small ?
I know I have asked many questions, but without this forum, I cannot seek for the help from someone else. Thank you again for your kindness.

Hi Michelle,

I mentioned the friction factor as an example because I don’t know your problem, so I can’t be sure of what you want to solve. The key point I wanted to highlight was:

Now, I’m not sure about the fact that the friction dimensionless number is what you need. Actually reviewing it I think that most probably is not what you need, because at the end of the day, in the case of laminar flow and in the case of zero-roughness walls it is only a function of the Reynolds number https://pdfs.semanticscholar.org/2b2e/7ce649a92fec2f482eb6c4920287d3f1342e.pdf.
So the workflow to follow is probably: \Delta p => … => Re. But again, I’m just thinking out loud… If you want help in your specific problem send me a PM with the actual description of your simulation problem and goal and I’ll try to help as soon as I’ll have a bit of time.
Clearly

(dx_lb/dt_lb) in lu is 21212 3.0344

is completely out of range…