[robin.trunk]

Hi Martins,

thank you for your answer. I added your issue to our tracking system.
I have a question on your videos, so correct me if I’m wrong:

I assume the flow is induced by the cube settling under gravity. This should induce a flow in positive y-direction (I can’t verify as the magnitude of velocity is depicted). The Magnus effect states that the particle moves to the side where rotation and flow align. This means a counter-clockwise rotation should lead to the particle drafting to the right. This means your results with the original rotation matrix in the first video are already correct?

Best regards
Robin

[robin.trunk]

Hi Thomas,

for now defining the constant seems to be the best solution.
I will try to reproduce the issue, which compiler do you use and what is the version of your compiler and Cygwin?

As you are using windows 10, I suggest you could also switch to the windows subsystem for linux (please see https://www.openlb.net/tech-reports/ TR5).

Best regards
Robin

[robin.trunk]

Dear Thomas,

I was not able to reproduce this exact error. Defining the constant is a good woraround. However to prevent such error in future releases, could you try to add
#define _USE_MATH_DEFINES
before alle the includes in this file and see if that solves the issue?

Best regards
Robin

[robin.trunk]

Hi Martins Brics,

if you refer to deflection after the particle reaches the bottom, it is probably not caused by “rolling” on the floor. The bottom wall hast no roughness, so there is no friction between particle and wall in this sense. It is most likely just pushed away from the wall by the fluid, when reaching the corner.

Best regards & a nice vacation
Robin

[robin.trunk]

Dear Martins Brics,

did you apply this rotation by settling a positive value for the angular velocity or acceleration for the particle?
It seems that for HLBM-2D the rotation is defined in a mathematice sense, meaning that a positive velocity leads to counter-clockwise rotation.
You can verify this by setting gravitation to zero and having a look at the velocity field.
We will have a look at that for the next release to make this more intutitive / consistent.

Best regards
Robin

[robin.trunk]

Dear bioluminescence,

M_PI is a constant with the value pi. It is defined in the math.h library. So you just have to add the line
#include<math.h>
Which version of OpenLB are you using? I cannot reproduce the error on version 1.3.1

Best regards
Robin

[robin.trunk]

Dear Nimmi,

I’m not too familiar with the simulation of thin fluid layers, but it probably depends on the case you are trying to simulate. In this paper (10.1016/j.camwa.2007.08.013) the flow over a curved surface in lubrication is investigated with basic LBM regarding the velocity profile.
If you are asking whether it is feasible to resolve a thin fluid layer it depends on the size of your domain and your computational power at hand.

Best regards
Robin

[robin.trunk]

Dear Nimmi,

a lubrication approximation is currently not implemented. I assume you mean a lubrication approcimation for thin fluid layers. Do you have s specific LBM approach or paper in mind?
As those cases are not described by standard Navier-Stokes anymore you will probably have to create a new dynamics object in OpenLB to modify the LBM collision step.

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

this charU enters the converter. It is only a discretisation parameter and has no influence on the settling of a sphere. You might want to look at the documentation of the converter in our user guide or the doxygen:
https://www.openlb.net/user-guide/
https://www.openlb.net/DoxyGen/html/d6/d92/classolb_1_1UnitConverter.html

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

for tau too close to 0.5 the simulation gets unstable, but a too large tau (depending on the case of application, e.g. tau=1) can lead to deviations from the physical setup.
You can apply no-slip boundaries, however the best results will be optained with a domain large enough. You might have to test that.
In your case epsilon is two orders of magnitude below the cell size physDeltaX. It will probably have almost no effect.

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

what is the particle size, i think you need at least 10 cells per sphere diameter to depict the sphere correctly. The Stokes assumption also states that the fluid extends infinitly in all directions (i.e. there are no walls). This has been investigated in some paper finding that you need several times the sphere diameter as distance to the walls in all directions.

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

could you explain what your setup is? When floating between two fludis stokes maybe does not hold.
The Stokes drag force is not directly applied in HLBM, but the overall hydrodynamic forces are calculated, which can give the Stokes drag force if flow regieme and geometry are chosen according to the Stokes assumptions.
What do you mean by Euler-Euler? HLBM consideres particles as distinct non-deformable objects, whereas in the Euler-Euler example case the particles are depicted by an advection-diffusion equation, describing the particles as density distribution instead of single objects. Therefore basic asumptions are differnt in this case.

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

if you want to use STL files you will have to create a new SmoothIndicator. I wanted to suggest to have a look at the other indicators and use them as a blueprint in the process of creating this new indicator.
Similar, if you want to combine some simple shapes, this will also require some programming and modification of some SmoothIndicators.
Or you can maybe simply you case to an object that can be described by an analytical equation.
As you described, you want the particle to float between the two phases. Setting the acceleration / force could be non-trivial as this force is currently just a global parameter. Therefore the current code might not be able to correctly depict an object’s buoyancy forces.

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

the objects for such particle simulations are described my SmoothIndicators, e.g. https://www.openlb.net/DoxyGen/html/db/d8b/classolb_1_1SmoothIndicatorCylinder3D.html
You will have to create a new one, which calculates the physical parameters (or you hardcode them if you know them) in the constructor. Also the ()-operator is used to decide wheater a given point is within the particle or outside. at this point you have to include the STL. You can probably take advantage of the included STL-reader : https://www.openlb.net/DoxyGen/html/d2/d60/classolb_1_1STLreader.html

I suggest you use an existing SmoothIndicator as a blueprint and have a look at the STLreader (it is applied e.g. in the cylinder3D example case.

Best regards
Robin

[robin.trunk]

Dear Zhangshi,

there could be several reasons. By the cuboid size do you mean the settling cube or the domain. If it is the particle, it would be larger than the domain. If it is the domain size, according to the resolution that would be more than 500.000.000 cells. Depending on the machine you are using maybe the RAM is not enough, this would lead to the process being killed during geometry creation.
On the other hand, are you already using STLs? In this case the STL file should be watertigth to be sure.
Do you get some kind of error message?

Best regards
Robin

[Author]

Posts