CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   Problem between rhoLTSPimpleFoam and mesh.update(); (http://www.cfd-online.com/Forums/openfoam-programming-development/115944-problem-between-rholtspimplefoam-mesh-update.html)

fredo490 April 10, 2013 01:04

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)


fredo490 April 10, 2013 03:59

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


All times are GMT -4. The time now is 13:58.