[Top][All Lists]
[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