espressomd-users
[Top][All Lists]
Advanced

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

Re: [ESPResSo-users] LBM, speed of sound, stability


From: Ulf Schiller
Subject: Re: [ESPResSo-users] LBM, speed of sound, stability
Date: Thu, 18 Dec 2014 09:30:08 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Hi Vincent,

I'm not sure whether there is a general way to identify instabilities.
Looking for oscillations in the non-hydrodynamic modes might be an
indicator. I gather it is not obvious how to distinguish numerical
instabilities from physical ones - think about onset of turbulence for
example. Pipe flows are maybe not such a good test as they are
unconditionally stable - this was Werner Heisenberg's PhD topic with
some certainty ;-)

Cheers,
Ulf

On 18/12/14 02:45, Vincent Ustach wrote:
> Ulf,
> 
> Are there are criteria that would give evidence for instabilities in a
> particular system? Would it be deviations from expected results, for
> example a non-parabolic velocity profile in pressure driven tube flow? 
> 
> Thanks,
> 
> Vincent Ustach
> 
> 
> On Wednesday, December 17, 2014, Ulf Schiller <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On 17/12/14 12:12, Ivan Cimrak wrote:
>     > Hi all,
>     >
>     > In one of his emails Ulf Shiller explained that:
>     > "you need to make sure that h*c_s^2/\nu is small to avoid nonlinear
>     > instabilities. h is the LB timestep, c_s is the speed of sound,
>     and \nu
>     > is the kinematic viscosity. In the D3Q19 model, c_s^2=1/3*a^2/h^2, so
>     > a^2/(3*\nu*h) must be small. It may work with values O(1) but it
>     is not
>     > guaranteed."
>     >
>     >
>     > Ulf, could you please give me the reason why this is necessary?
>     And what
>     > does it mean "is small"? Are the values 0.1 - 0.99 ok?
> 
>     Hi Ivan,
> 
>     the standard lattice Boltzmann algorithm is typically thought to be
>     second order accurate in time, however, if you look at the
>     discretisation of the collision operator (usually Crank-Nicolson), the
>     error is actually of the order O((h/\tau)^3) where \tau is the viscous
>     relaxation time (or BGK relaxation time). The latter is related to the
>     viscosity by \nu=c_s^2*\tau where c_s is the speed of sound. Hence the
>     grid Reynolds number h/\tau=h*c_s^2/\nu needs to be small. Now, in LB
>     there is a subtle cancellation of errors of the Crank-Nicolson
>     discretisation and the splitting error, such that the standard LB
>     algorithm approximates the slow manifold of solutions to the discrete
>     velocity model even at values of \tau/h beyond unity (an intriguing side
>     effect of this is that the exact solution of the collision operator does
>     produce excessive decay of shear waves due to the lack of said
>     cancellation). Another way to phrase it is that the LBM disconnects from
>     kinetic theory and can work in the over-relaxation regime (i.e. negative
>     eigenvalues of the collision operator). Some details of the derivation
>     are given in http://dx.doi.org/10.1016/j.cpc.2014.06.005 and references
>     therein (in particular Brownlee et al. and Paul Dellar). In practise,
>     instabilities may arise at the higher moments and couple into the
>     Navier-Stokes dynamics. I'll mention in passing that coupling particles
>     to the LB fluid involves singular forces that may also affect stability.
>     If this actually occurs will depend on the characteristics of the flow
>     under consideration; for laminar flow and non-stiff coupling there is
>     probably no problem.
> 
>     Best wishes,
>     Ulf
> 
>     --
>     Dr Ulf D Schiller
>     Centre for Computational Science
>     University College London
>     20 Gordon Street
>     London WC1H 0AJ
>     United Kingdom
> 
> 
> 
> 
> -- 
> --Vincent Ustach
>   University of California, Davis
> 


-- 
Dr Ulf D Schiller
Centre for Computational Science
University College London
20 Gordon Street
London WC1H 0AJ
United Kingdom

Phone: +44 (0)20 7679 5300



reply via email to

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