[takamori67]

Hi Robin,
my parameters are charL = 5mm, charU= 220m/s, charNu= 0.000015 m^2/s so that I get Re = 75000.
My spacial resolution right now is at latticeL = 0.0002m, with these settings I get a time discretization of 10^-7 s/step, which for my purposes is way too fine. I would like to increse my physTime by a factor of 100, but all the parameters for physTime are fixed. Is there a way to change the pysical time per time step manually?

I am already using the Consitent Strain Smagorinsky turbulence model for my under resolved mesh.

Best,
Sumit

[takamori67]

Thank you!

[takamori67]

Hi Robin,

thank you for the information, especially for the great literature source.

Your examples and the converter doxygen gave me a better understanding.

What I am trying to do is having a relatively high charU = 200m/s and a very small latticeL < 0.0001. With latticeU at around 0.3 (higher values tend to get unstable), I get very small physical time steps at 10^-7s (with physTime= latticeL*latticeU/charU * latticeTime(=1)). For my purposes I only need about 10^-5s. Is there a way to increase the time step length other than changing charU, latticeL or latticeU, because these are quite fixed in my case.

[takamori67]

Hi Robin,

for pressure I have initialized the whole fluid with 0 Pa and then let the inlet pressure slowly increase to 100Pa with constant outlet pressure of 0Pa.

Thank you for the example!
So the inlet velocity in physical units is calculated by charU * latticeL ? In your example the physical inlet velocity is 0.002m/s? Accordingly, to have an inlet velocity of 100m/s at a latticeL of 0.0001, I have to set charU to 10^6 m/s?
Then what does latticeU do other than defining the time step with physTime= latticeL*latticeU/charU? Where does the compressibility effects come into play?

Thank you for the help with the scaling factor for CirclePoiseuille3D, that was really useful.

Best,
Sumit

[takamori67]

Hi Robin,

short follow up:
if I want to get the physical velocity at location “point”, I just change the code to this, right?

SuperLatticePhysVelocity3D<T, DESCRIPTOR> velocity(sLattice, converter, false); // create functor
AnalyticalFfromSuperF3D<T> intpolateVelocity( velocity, true ); // prepare functor to accept physical locations by interpolation
T point[3] = {1.,0,0}; // physical location
T u1[3]={0,0,0};
intpolateVelocity( &p1,point ); // compute velocity at point1 and write value in u1
std::cout << “u1_x= ” << u1[0] << std::endl;

[takamori67]

Hi Robin,
I looked at the geometry file in Paraview, and indeed I found a fatal flaw. The no slip boundary extended from the wall all over the outlet. I figured this happened because the cylinder defining the pipe and the cylinder defining the outlet were fit to be touching, but without overlap. This caused the functor assinging the geometry numbers to assining a wall BC to the whole surface of the flow field(including the outlet). When the two cylinders are made to overlap by 2*latticeL, the issue is solved.

Thank you so much for your help!

Best,
Sumit

[takamori67]

Hi Robin,

thank you for your help!
So if I understand correctly, if I set charU to be let’s say 100m/s, and latticeU to be 0.1m/s and feed latticeU as velocity boundary value to the boundary function at the inlet: Then the converter sets a latticeU of 1m/s in the lattice to be equal to 100m/s in physical values and consequently the physical inlet velocity would be 10m/s?

As for the pressure inlet, I am using the polynomial start scale as a smooth start scale.

Best,
Sumit

[takamori67]

Alright, that makes sense. Thank you!

[takamori67]

Thanks for helping me with this problem as well, Robin!

I’ll try it out.

[takamori67]

Hi Robin,
thanks for the insight!
When I initialize it with the rho converted from the pressure (with a transition factor) it succeeds to compile

Quote:

AnalyticalConst3D<T,T> rhoIn(frac[0]*converter.rhoFromPhysicalPressure(pIn));

However, when I initialize it with a value, let’s say 1 and after that set it to the convertetd rho, it fails to compile.

Quote:

AnalyticalConst3D<T,T> rhoIn(1);
rhoIn = frac[0]*converter.rhoFromPhysicalPressure(pIn);

Is this because once initialized, the AnalyticalConstant3D is cannot be changed?

Thanks for the great and quick help, Robin!

Best,
Sumit

[takamori67]

Hi Robin,
I’m having issues with the set up of the boundary values.

Quote:

AnalyticalF3D<T,S>(1) rhoIn;
rhoIn = converter.rhoFromPhysicalPressure(pIn);
sLattice.defineRho( superGeometry, 3, rhoIn);

defineRho expects the density in the AnalyticalF3D format. However, how do I define my inlet density rhoIn as a AnalyticalF3D correctly? The doxygen page for AnalyticalF3D is somewhat cryptic.

Best, Sumit

[takamori67]

Hi Robin,
thank you for the information! I will try it out.

Best,
Sumit

[takamori67]

Dear Matthias,
thanks, that definitely sounds great! However, since I’m working on a thesis right now, I would really appreciate an answer before March 😉

[takamori67]

Thanks a lot, Patrick and Matthias! Your input was very insightful.

For the time being, I decided to first get my simulation set up and going with an under resolved mesh and a Smagorinsky turbulence model, in order to limit computation time. Then I will move on to scaling the mesh.

While setting up and testing the case, a few questions have come up:
-when applying a velocity boundary condition (Poiseuille velocity profile) at the pipe inflow and pressure boundary condition at the outlet, the results look a lot like a free jet, with a distinct velocity profile at the beginning that breaks down towards the end, with velocities close to zero at the outlet. Have I set up my boundary conditions incorrectly? Or should I just increse the Smulation time to let the flow build up.
– I have considered using a pressure boundary condition at the inlet, since this is often used in RANS based solvers. Would that be appropiate for LBM? And how do I set up the pressure boundary value, since I can only use defineRho?
-I have noticed, that the value of charU has a huge impact on computaion speed. When playing with the values of charU and charNu to reach a high Re, computaion time was almost proportional to charU, with unchanged number of voxels. Is there a reason behind this?
-can I expoit the symmetry of the pipe by just simualting a wedge (e.g. a quarter of the circle) and using periodic boundaries for the planes neighboring the outer flow field?

Thanks in advance for your kind support.

Best, Sumit

[takamori67]

Dear Patrick,
thank you so much for the quick and very helpful reply, I greatly appreciate your support.

If I understand correctly, the turbulence model is implemented in the code by substituting th BGK collision operator by a modified one with turbulence modelling, thus reulting in a different omega, and a higher viscosity respectively. This is a very interesting phenomenon, do you know any literature, so I can find out more about this?

What if, instead of reducing the viscosity in order to get a high Re, we increase the velocity (which would be latticeU or charU?)?

My ultimate goal is to finely resolve turbulences, so in the end I have to use a well resolved setup wit BGK anyway. But what would “well resolved” be like? Is there a formula or rule of thumb, or do I need to conduct a mesh refinement study. In this case, which resulting quantity do I need to look at to asses if the mesh is fine enough.

Sorry for the flood of questions.

Best,
Sumit

[Author]

Posts