CFD Online Discussion Forums - Problem between rhoLTSPimpleFoam and mesh.update();

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)

- - Problem between rhoLTSPimpleFoam and mesh.update(); (https://www.cfd-online.com/Forums/openfoam-programming-development/115944-problem-between-rholtspimplefoam-mesh-update.html)

Problem between rhoLTSPimpleFoam and mesh.update();

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

Code:

    surfaceScalarField phid

    (

        "phid",

        fvc::interpolate(psi)

       *(

            (fvc::interpolate(HbyA) & mesh.Sf())

          + fvc::ddtPhiCorr(rAU, rho, U, phi)

        )

    );

Code Error:

Code:

--> 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)

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).