[fredo490]

Dear All,
I've modified the rhoPimpleFoam solver (OF2.2) to add a mesh morphing. It is a very small node displacement (1/10 of the first cell height) so I didn't setup the absolute phi.

With the rhoPimpleFoam solver, everything goes well. However, if I apply the same modification to the rhoLTSPimpleFoam, it doesn't work anymore. I get an error about dimensions which seems to come from a rho factor (kg.m-3 missing).

I've found that if I remove "mesh.update();" from my solver, it works perfectly. Then, I found that the error comes from the "pEqn.H" and more precisely from the phid calculation.

Has anyone an idea of the origin of the problem ? It seems to come from the localEuler scheme but I can't identify the source.

Thx, Fred

Edit:
If I set the ddt scheme to Euler, my simulation runs smoothly. However, with a localEuler, the simulation crash during the first iteration.

Origine of the Error

    surfaceScalarField phid
    (
        "phid",
        fvc::interpolate(psi)
       *(
            (fvc::interpolate(HbyA) & mesh.Sf())
          + fvc::ddtPhiCorr(rAU, rho, U, phi)
        )
    );

Code Error:

--> FOAM FATAL ERROR: 
LHS and RHS of + have different dimensions
     dimensions : [0 3 -1 0 0 0 0] + [1 0 -1 0 0 0 0]


    From function operator+(const dimensionSet&, const dimensionSet&)
    in file dimensionSet/dimensionSet.C at line 458.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::operator+(Foam::dimensionSet const&, Foam::dimensionSet const&) at ??:?
#3  Foam::tmp<Foam::GeometricField<Foam::typeOfSum<double, double>::type, Foam::fvsPatchField, Foam::surfaceMesh> > Foam::operator+<double, double, Foam::fvsPatchField, Foam::surfaceMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > const&) at ??:?
#4  
 at ??:?
#5  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6  
 at ??:?
Aborted (core dumped)

[fredo490]

Finally I can answer my question.

The problem comes from the fact that mesh.update() turns mesh.moving() to be true (no surprise here). The problem is located in the "localEulerDdtScheme.C" in src/finiteVolume/finiteVolume/ddtSchemes/kicakEulerDdtScheme.

The scheme ddtPhiCorr() is simply not implemented for a compressible solver having the mesh moving. There is a "if (mesh().moving())" leading to a single scheme which is only suitable for incompressible solver. However, if mesh().moving()=false, the scheme has 3 choices depending of the dimension of phi and U.

To solve my problem I've simply decided to ignore the mesh motion ! indeed, my displacement is of about 1e-7 meter per time step (which are 1e-3 second) where my first cell height is about 1e-4.

To do so, only add: "mesh.moving(false);" after your "mesh.update();".
With this code, the following solver think that the mesh is steady and so it doesn't compensate the motion of the boundary/mesh (which is wrong but acceptable for very small displacement).