CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

Problem between rhoLTSPimpleFoam and mesh.update();

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 10, 2013, 01:04
Default Problem between rhoLTSPimpleFoam and mesh.update();
  #1
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 236
Rep Power: 7
fredo490 is on a distinguished road
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 is offline   Reply With Quote

Old   April 10, 2013, 03:59
Default
  #2
Senior Member
 
HECKMANN Frédéric
Join Date: Jul 2010
Posts: 236
Rep Power: 7
fredo490 is on a distinguished road
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).
fredo490 is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with inconsistent patches (AMI, interDyMFoam) jrrygg OpenFOAM Running, Solving & CFD 3 February 1, 2013 04:23
Problem with FloatingObject Leech OpenFOAM Running, Solving & CFD 10 March 29, 2012 15:24
MPI comunication wrong after use of gather/scatter matteoL OpenFOAM 1 October 10, 2011 13:19
mesh.update problem in a new FSI solver ICL OpenFOAM 0 October 8, 2011 14:16
the problem about"Max(gamma)>1" zhajingjing OpenFOAM 6 April 5, 2010 02:33


All times are GMT -4. The time now is 12:47.