[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