espressomd-devel
[Top][All Lists]
Advanced

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

Re: [ESPResSo-devel] [ESPResSo-users] Simulation of fluid using LB-metho


From: Stefan Kesselheim
Subject: Re: [ESPResSo-devel] [ESPResSo-users] Simulation of fluid using LB-method
Date: Thu, 30 Jan 2014 15:01:50 +0100

Hi everybody,

we have checked our LB code again.

This is our pressure conversion in the output routines:

p_pi[0] = pi[0]/tau/tau/lbpar.agrid/lbpar.agrid/lbpar.agrid;
and this is our velocity conversion:
p_u[0] = j[0]/rho/tau/lbpar.agrid

Both look wrong, by a factor of a^2, consistently with errors in the force 
density conversion.

Sorry, I have found that already yesterday and forgot to send this mail.
Cheers
Stefan





On Jan 29, 2014, at 10:59 AM, Stefan Kesselheim <address@hidden> wrote:

> Hi everybody,
> 
> On Jan 27, 2014, at 6:35 PM, Ulf Schiller <address@hidden> wrote:
> 
>> Hi,
>> 
>> can anybody explain the rationale of the following lines to me? I'd have 
>> expected an exponent of either -1 or 2 for the grid spacing, depending on 
>> whether ext_force is a force or a force density. In lattice units there is 
>> no difference.
>> 
>> #ifdef EXTERNAL_FORCES
>>   // unit conversion: force density
>>     lbfields[index].force[0] = lbpar.ext_force[0]*pow(lbpar.agrid,4)*tau*tau;
>>     lbfields[index].force[1] = lbpar.ext_force[1]*pow(lbpar.agrid,4)*tau*tau;
>>     lbfields[index].force[2] = lbpar.ext_force[2]*pow(lbpar.agrid,4)*tau*tau;
>> #else
> 
> I'm also surprised. I however checked that part relatively carefully a couple 
> of years ago. The unit of the force density is energy/length^4, or 
> mass*time^2/length. It somehow looks like the two were mixed up in these 
> lines. 
> 
> We have a test case which is in principle sensitive to that. The pressure 
> tensor test case checks the diagonal elements of the pressure tensor by 
> applying a force density normal to a wall (=hydrostatic pressure). In 
> principle it is possible that several unit conversion problems are present 
> which entirely cancel out as long as Stokes flow is concerned. This can be 
> possible because the flow field is linear in this case, and a factor in the 
> force density might well be compensated for by an inverse factor e.g. in the 
> output of the flow field. Problems like these are quite difficult to debug, 
> because one would in principle need a nonlinear flow field case for which 
> reference data is somewhat difficult to get.
> 
> I'll be looking deeper into that in the next couple of days.
> 
> Cheers
> Stefan




reply via email to

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