[Nicolas]

Dear Henderson_C,

first, please verify that you are meeting the general LBM stability requirements (according to e.g. [Krueger17](https://link.springer.com/book/10.1007/978-3-319-44649-3). You should then set your resolution in such a way that your particle is represented by a sufficient number of grid cells (e.g. 10 cells in diameter). You can find out the specific minimum requirement for your setup by conducting a grid convergence study and evaluating the respective error of e.g. the hydrodynamic force in the sedimentation direction. For a more detailed description of sensible parameters, I would like to again refer to [Trunk21](https://www.mdpi.com/2079-3197/9/2/11) or similar literature.

In case you want to gain some more in-depth insights, you should consider joining the next occurrence of our annual [Spring School](https://www.openlb.net/spring-school-2023/).

[Nicolas]

Dear Henderson_C,

I referenced the article in order to point out that the respective scenario can in general be investigated with OpenLB. A different output is to be expected for your 2D version (compared to the referenced 3D version) as the surface force to volume force ratio is significantly different for the same parameter setup. You need to be aware that transferring a real-world physical problem, which is inherently three-dimensional, into a 2D version is not straight forward (as it can be reasonable to have a 2D circle both represent a Cylinder or a Sphere in 3D depending on the assumptions). If you want to use the exact parameters used in the publication, you need to switch to 3D instead. If you want to stick to 2D you may want to look for a published 2D version for respective reference parameters.

Best regards,

Nicolas

[Nicolas]

Dear Henderson_C,

assuming you are using version 1.5, there should be no general issues preventing you from investigating a single-sphere sedimentation setup. This has been done in 3D e.g. in [Trunk21](https://www.mdpi.com/2079-3197/9/2/11). As the terminal settling velocity results from an equilibrium between the respective forces acting on the particle, it can most likely not be achieved by “playing” with the parameters in a given domain, but requires a consistent parameter setup. It is worth noting at this point, however, that some setups will lead to large settling distances before hitting the terminal velocity. The default domain size of the dkt2d case will most likely not suffice in most cases and needs to be enlarged significantly.

Best regards,

Nicolas

[Nicolas]

Dear Evan,

before considering any particle related issue, please ensure that the described problem does not appear in the particle-free flow after the same duration already. If it does, you need to respect stability and accuracy limits first!

Best,

Nicolas

[Nicolas]

Dear Evan,

please always refer to the version of OpenLB you are using, as there are major changes especially in the particle framework.

Assuming, you are using the current one (v 1.5) though, you can do the following with respect to the implementation in settlingCube3D:

The particle motions is taken care of by the

VerletParticleDynamics<T,PARTICLETYPE>

(located in dynamics/particleDynamicsBase.h). This Dynamics-Class is applied to every particle in the example file. Inside, the

velocityVerletIntegration<T,PARTICLETYPE>

(located in functions/particleMotionFunctions.h) is called, which is responsible for modelling Newton’s motion in all cartesion directions.

In order to restrict this calculation to e.g. the z-axis only, just limit the respective position update here to e.g the third vector component (here associated with the z-direction).

You can then incorporate those changes into a new Dynamics Object (similar to the VerletParticleDynamics) and apply this one to your particles in the example file instead.

Best,
Nicolas

[Nicolas]

Dear d.sun,

yes, this is possible. In order to avoid any movement, remove particleDynamics.simulateTimestep("verlet"); from the case file. This function includes:
1. computation of the boundary force
2. update of particle dynamics (via velocity verlet algorithm)
3. writing the particle information onto the grid
Those functions will then of course not be called anymore and you can decide which ones you want to add back in manually depending on your needs.
Without 3., you most likely want to avoid the particle to be removed from the grid every timestep (since it is not added anymore). For that, simply set the boolean template parameter isStatic to true by changing PorousParticleBGKdynamics<T, DESCRIPTOR, false> to PorousParticleBGKdynamics<T, DESCRIPTOR, true>.

As a side note: What you asked for will be much simpler in the new particle framework which will be included in our next release next year.

Best,

Nicolas

[Nicolas]

Hello Ramiro,

I assume, you did not implement any custom treatment of specific fields and your are simply referring to the output of the macroscopic velocity. Furthermore I am assuming that you are using Paraview to generate your images. In this case, you might be dealing with some harmless visualization artifacts. Please make sure, to use the most recent Paraview version. In order to check the output correctness, you can use the “Extract Block” filter in Paraview to check individual blocks. If your are only interested in obtaining a continuous surface or volume representation, please use Paraview’s “Resample To Image” Filter.

Best,

Nicolas

[Nicolas]

correction: “compressible” should of course be “incompressible”…

[Nicolas]

Dear Sahil,

the relation between density and pressure you mentioned is correct and holds in this context for the LBM considering the respective equation of state. A proper derivation can be found in many LBM related literature (e.g https://www.springer.com/de/book/9783319446479).
Setting a specific characteristic physical pressure, however, is not solely an LBM related issue. As the compressible/slightly-compressible Navier-Stokes equation does not include the absolute pressure, but only the pressure gradient, changing the default value does not have any effect on the fluid flow solution (despite, obviously the resulting absolute pressure). As this is a matter of general fluid dynamics, you might want to have a look at respective literature for further insights.

Best,

Nicolas

[Nicolas]

Dear Sahil,

generally, it is a good idea to set the initial lattice density to unity, as described in the book you referred to. You will find this very approach in most of our examples. Your usage of the OpenLB methodology seems to be correct.
The density derived from the first moment of the distribution function, however, will change during your simulation. In order to end up with a pressure difference in a force free flow you need to have some proper boundary conditions applied to your walls. It might be a good idea to start with a common setup of velocity inflow, pressure outflow and no-slip wall condition first and see whether the expected pressure drop can be observed, both reflected by the console output and the VTK writout. You can then adapt this to a double velocity condition setup and see, whether your issues still persist.

Best,

Nicolas

[Nicolas]

Hello Abhijeet,

in our latest release (1.4r0), periodic boundary conditions can only be applied to the fluid solution and not to the resolved particle dynamics used in the dkt2d example. This functionality has, however, already been added to the development version and will be part of the next official release. Unfortunately, a specific release date does not yet exist.

Best,

Nicolas

[Nicolas]

Dear Junwei Guo,

after intruducing HLBM to OpenLB in 2017 there have been various minor, but also some major changes, including the momentum exchange algorithm. A lot of them are documented in a more recent publication on HLBM and the OpenLB user guide. You are strongly advised to contemplate both. Another more up-to-date publication is being worked on at the moment, however no specific date for it can be given for now. Here, some further changes to the algorithm will be discussed, which will eventually be part of our next release, which is scheduled for the end of this very month. In case you are looking for the greatest consistency between publications and the implementation, you might need to await the upcoming release and our next HLBM related publication. Another option is of course to attend our next OpenLB spring school, which will give you the opportunity to talk with the developers directly.
I hope, this is of any help for now.

Best,
Nicolas

[Nicolas]

Dear Junwei,

before answering your questions, I want to inform you, that we are planning on releasing a new version of OpenLB (v1.4) next month. This version will fortunately include a SmothIndicatorEllipsoid3D, which you might use instead of your own implementation. Nonetheless I am going to refer to your questions in the following:

The operator is the core function used in the functor concept. It expects an input in lattice coordinates and will eventually return a value, which is to be specified in the operator function’s body and usually depends on the input itself. This enables a simple way of implementing e.g. mathematical functions, filters or masks, which can be applied to your calculation domain. For any further questions regarding the functor concept, please refer to section 2.5 in the official OpenLB user guide.

Best,

Nicolas

[Nicolas]

Dear Chris,

the coupling of openlb and DEM does not exclude the usage of partially saturated methods (PSM) as proposed by [1]. In fact, in [2] we compared different fluid-solid interface approaches to study the Galilean invariance for vortex-induced vibrations with OpenLB including different PSM approaches. A collision, based on a weighting of the collision operators according to [1], can be included into your code by using the PSMBGKdynamics in the latest release of OpenLB (v1.3 – 1).

Best regards,
Nicolas

Refs:
[1] D. R. Noble and J. R. Torczynski. A Lattice-Boltzmann Method for Partially Saturated
Computational Cells. International Journal of Modern Physics C, 09(08):1189–1201, 1998
[2] M. Haussmann et al. Galilean invariance study on different lattice Boltzmann fluid-solid interface approaches for vortex-induced vibrations. Computers and Mathematics with Applications, 2020

• This reply was modified 4 years ago by Nicolas. Reason: Adding Link

[Nicolas]

Dear Zhangshi,

thank you a lot for the suggestion, however this is already implemented and has been used by Trunk et al.. Although it is not part of the current release 1.3–1, it might be part of the next one.

Best,
Nicolas

• This reply was modified 4 years, 2 months ago by Nicolas.

[Author]

Posts