espressomd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo-users] Lattice Boltzmann External Force


From: Stefan Kesselheim
Subject: Re: [ESPResSo-users] Lattice Boltzmann External Force
Date: Thu, 9 Feb 2012 12:59:18 +0100

Hi Wolfgang, hi Espresso Community,

Am 09.02.2012 um 12:40 schrieb Ulf Schiller:

> The scaling of the force depends on the units. If it is a volumetric force, 
> then it also has to be scaled with the grid spacing. Usually this is done in 
> the initialization routine, so it does not have to be multiplied every time.

It is supposed to be a force density, and not the force pore node. I did check 
that, but it might be that I still messed it up :-).

> Nevertheless, even with the correct scaling you will notice a deviation from 
> the analytic solution. That is a discretization artifact and can be improved 
> by means of higher order boundary conditions using interpolation. Not that 
> this requires adjusting the collision eigenvalues in order to make the 
> viscosity independent of the boundary location.

> On 02/09/2012 11:49 AM, Wolfgang Riefler wrote:
>> Implementing this in my source code indeed gave me the right solution
>> for a grid size of a=1. Changing this to a=0.5 again caused an offset.
>> Could it be possible that the force has to be scaled not only by time,
>> but also by the grid size? I have noticed similar scalings in older
>> versions of Espresso (Version 2.1.2).

I have noticed that, too. The reason is probably, exactly what Ulf wrote: In 
the LB unit system you change the viscosity, and its scales like a^3. If this 
makes the viscosity too large, the quality of the bounce back boundary 
condition may severely decrease. Try decreasing the viscosity (say 0.1) and see 
if the offset still remains.

>> On another note, is there any progress, or is it planned to allow the
>> user to set the node populations manually (like e.g. the velocity)? I
>> have noticed that the declaration of the corresponding function is
>> already implemented, but the function is empty.

I thought we had implemented that. At the moment I am quite busy (I am on a 
conference), but I if you bug me a bit, I can implement it. Setting velocities 
manually (and instantanously) is not implemented because it makes not too much 
sense most of the times. If one'd want to have in- and outflow boundary 
conditions, one would better implement this in C, and about that I am not at 
all familiar how these flux BCs work. Of other situation where one would need 
it, I am not aware at the moment, except for debugging purpose.

What are you planning to simulate? I'd be glad to give a few more hints :-).

Cheers and good luck,
Stefan

Stefan Kesselheim
Institute for Computational Physics
University of Stuttgart
address@hidden






reply via email to

[Prev in Thread] Current Thread [Next in Thread]