CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

LTS - interFoam - problems

Register Blogs Community New Posts Updated Threads Search

Like Tree1Likes
  • 1 Post By KateBradbrook

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 21, 2016, 08:55
Default LTS - interFoam - problems
  #1
Member
 
Join Date: Nov 2009
Posts: 56
Rep Power: 16
fusij is on a distinguished road
Hello,

I have a free-surface flow that is similar to the waterchannel tutorial. I am using Local Time Stepping (LTS) but I have convergence problems. I will below go through my case step by step and provide the case files if someone is interested to take a look and give me some pointers.

A schematic of the geometry can be seen below



I have used cfMesh to create the mesh, here is the output of the checkMesh -allGeometry -allTopology:
Code:
Create time

Create polyMesh for time = 0

Enabling all (cell, face, edge, point) topology checks.

Enabling all geometry checks.

Time = 0

Mesh stats
    points:           385360
    internal points:  288677
    edges:            1074519
    internal edges:   882306
    internal edges using one boundary point:   93367
    internal edges using two boundary points:  0
    faces:            994222
    internal faces:   898692
    cells:            305063
    faces per cell:   6.20499
    boundary patches: 5
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     268418
    prisms:        2112
    wedges:        0
    pyramids:      5269
    tet wedges:    0
    tetrahedra:    2336
    polyhedra:     26928
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            6   6170
            7   3188
            8   599
            9   11939
           10   1
           12   3697
           13   1
           15   1273
           16   1
           18   54
           21   4
           24   1

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Topological cell zip-up check OK.
    Face-face connectivity OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology Bounding box
                    atmo    29308    30048  ok (non-closed singly connected) (34.1243 215.677 108.957) (71.5834 236.001 114)
                   inlet     3800     4181  ok (non-closed singly connected) (51.0844 217.546 107.302) (71.5835 226.81 110.267)
                  outlet     3283     3598  ok (non-closed singly connected) (21.1025 219.023 104.886) (25.9396 238.029 108.5)
             sula-fleyti     9304     9450  ok (non-closed singly connected) (31.7173 224.968 105.022) (35.0795 226.499 108.936)
                   walli    49835    51290  ok (non-closed singly connected) (21.1025 215.677 104.886) (71.5835 238.029 110.267)

Checking geometry...
    Overall domain bounding box (21.1025 215.677 104.886) (71.5835 238.029 114)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (1.89714e-16 1.40128e-15 1.1662e-15) OK.
    Max cell openness = 3.27551e-16 OK.
    Max aspect ratio = 10.2315 OK.
    Minimum face area = 0.000174025. Maximum face area = 3.46417.  Face area magnitudes OK.
    Min volume = 1.50399e-06. Max volume = 8.48143.  Total volume = 3955.37.  Cell volumes OK.
    Mesh non-orthogonality Max: 64.2831 average: 9.91544
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 2.10038 OK.
    Coupled point location match (average 0) OK.
 ***Error in face tets: 16 faces with low quality or negative volume decomposition tets.
  <<Writing 16 faces with low quality or negative volume decomposition tets to set lowQualityTetFaces
    Min/max edge length = 0.00357058 1.46541 OK.
   *There are 2062 faces with concave angles between consecutive edges. Max concave angle = 63.3745 degrees.
  <<Writing 2062 faces with concave angles to set concaveFaces
    Face flatness (1 = flat, 0 = butterfly) : min = 0.80978  average = 0.999301
    All face flatness OK.
    Cell determinant (wellposedness) : minimum: 0.0415301 average: 12.492
    Cell determinant check OK.
 ***Concave cells (using face planes) found, number of cells: 2444
  <<Writing 2444 concave cells to set concaveCells
    Face interpolation weight : minimum: 0.0647744 average: 0.45461
    Face interpolation weight check OK.
    Face volume ratio : minimum: 0.0177947 average: 0.801404
    Face volume ratio check OK.

Failed 2 mesh checks.

End
My interpretation of the failed mesh checks is that I should be able to solve a case on this mesh, low number of lowQualityTetFaces should not have a detrimental effect on the convergence. I have tried several configurations for cfMesh and it always seems to create a certain amount of lowQualityTetFaces.

Here is an image showing some of the lowQualityTetFaces in the domain



This is a list of how I set the boundary conditions, provided by patchSummary
Code:
Valid fields:
    volScalarField    nut
    volScalarField    alpha.water
    volVectorField    U
    volScalarField    k
    volScalarField    alpha.water.org
    volScalarField    p_rgh
    volScalarField    omega

patch    : atmo
    scalar        nut        calculated
    scalar        alpha.water        inletOutlet
    scalar        k        inletOutlet
    scalar        alpha.water.org        inletOutlet
    scalar        p_rgh        totalPressure
    scalar        omega        inletOutlet
    vector        U        pressureInletOutletVelocity

patch    : inlet
    scalar        nut        calculated
    scalar        alpha.water        variableHeightFlowRate
    scalar        k        fixedValue
    scalar        alpha.water.org        variableHeightFlowRate
    scalar        p_rgh        fixedFluxPressure
    scalar        omega        fixedValue
    vector        U        variableHeightFlowRateInletVelocity

patch    : outlet
    scalar        nut        calculated
    scalar        alpha.water        zeroGradient
    scalar        k        inletOutlet
    scalar        alpha.water.org        zeroGradient
    scalar        p_rgh        fixedFluxPressure
    scalar        omega        inletOutlet
    vector        U        zeroGradient

group    : wall
    scalar        nut        generic
    scalar        alpha.water        zeroGradient
    scalar        k        generic
    scalar        alpha.water.org        zeroGradient
    scalar        p_rgh        fixedFluxPressure
    scalar        omega        generic
    vector        U        fixedValue

End
I use setFields to have a initial water level in my domain as seen below

I have basically adopted the fvSchemes and fvSolution from the DTCHull tutorial that uses localEuler (LTS) as its ddt scheme. I squeezed down the tolerances on the solvers to lower the continuity error in each timestep and also played with the damping/smoothing coefficients. You can find the controlDict, fvSchemes and fvSolution files attached to this post.

I am confused now if the mesh, B.C. or schemes/solvers are causing the divergence. If you can give me comments on this case that would be appreciated.

You can find the case files here: case-files
Attached Files
File Type: txt controlDict.txt (1.9 KB, 113 views)
File Type: txt fvSchemes.txt (1.5 KB, 120 views)
File Type: txt fvSolution.txt (2.7 KB, 115 views)

Last edited by fusij; April 21, 2016 at 13:47.
fusij is offline   Reply With Quote

Old   May 4, 2016, 02:30
Default
  #2
New Member
 
Kate Bradbrook
Join Date: Nov 2015
Posts: 12
Rep Power: 10
KateBradbrook is on a distinguished road
What type of divergence appears first?

If bounding message for turbulence parameters - in my experience, this implies grid problems - look at grid in area of high turbulence parameters.

If you quickly get strange velocity vectors or alpha behavious at/near boundaries, then it is probably a BC issue. At outlet you have fixedFluxPressure for P and zeroGradient for U. Whilst this can be consistent for simple cases, there is also the potential for small inconsistencies (particularly -ve velocities) to feedback into strange behaviour. Especially when starting from a zero velocity condition with LTS. Try a fixed value for one of them (e.g. calculate U based on inflow/area at outlet for your initial water level and keep P as fixedFluxPressure; or use a free-outfall (P=0) or hydrostatic pressure condition and keep U as zeroGradient) - at least to get a stable solution and then you can adjust later....

Hope these thoughts help. If things blow up quickly it IS normally grid, BC, or initial conditions - changing solution schemes or parameters in my experience only delays divergence if there is an underlying issue with problem specification, so best to go back to less restrained tolerances and know more quickly if it is going to work or not!
aow likes this.
KateBradbrook is offline   Reply With Quote

Old   May 11, 2016, 21:30
Default
  #3
Member
 
Join Date: Nov 2009
Posts: 56
Rep Power: 16
fusij is on a distinguished road
Hey Kate, thank you for your answer.

After fixing the pressure at the outlet, everything started to run smoothly. Now I converge in 10000-12000 timesteps using LTS with Co=10.

So having few lowQualityTetFaces in your domain is not prohibiting convergence.

My issues came from the BC's. Letting the pressure float at the outlet and only fixing pressure for atmosphere BC was not enough.
fusij is offline   Reply With Quote

Old   May 25, 2016, 05:22
Default
  #4
Senior Member
 
Franjo Juretic
Join Date: Aug 2011
Location: Velika Gorica, Croatia
Posts: 124
Rep Power: 16
franjo_j is on a distinguished road
Send a message via Skype™ to franjo_j
Quote:
Originally Posted by fusij View Post
Hey Kate, thank you for your answer.

After fixing the pressure at the outlet, everything started to run smoothly. Now I converge in 10000-12000 timesteps using LTS with Co=10.

So having few lowQualityTetFaces in your domain is not prohibiting convergence.

My issues came from the BC's. Letting the pressure float at the outlet and only fixing pressure for atmosphere BC was not enough.
My experiences show that lowQualityTetFaces cause problems to lagrangian simulations. Furthermore, the mesh is useless if you have any negative pyramids. In other cases, convergence depends on your settings and the problem at hand.
__________________
Principal Developer of cfMesh and CF-MESH+
www.cfmesh.com
Social media: LinkedIn, Twitter, YouTube, Facebook, Pinterest, Instagram
franjo_j is offline   Reply With Quote

Old   May 25, 2016, 05:59
Default
  #5
Member
 
Join Date: Nov 2009
Posts: 56
Rep Power: 16
fusij is on a distinguished road
Quote:
Originally Posted by franjo_j View Post
My experiences show that lowQualityTetFaces cause problems to lagrangian simulations. Furthermore, the mesh is useless if you have any negative pyramids. In other cases, convergence depends on your settings and the problem at hand.
Thanks for the input. I have noticed that cfMesh creates these lowQualTetFaces quite often, at least in my case. They are spread at regular intervals and at a certain distance from the surface. This distance changes when I thicken/decrease my refinement area but does not remove these faces. Do you know why this could be? Has it something to do with cfMesh or is it problem dependent?

I really like using cfMesh, especially the ease of use compared to other OS meshers. It gives you good meshes in a much shorter time, both because of easy setup and quick run-times.
fusij is offline   Reply With Quote

Old   May 7, 2019, 10:17
Default Error
  #6
New Member
 
walid
Join Date: Apr 2019
Posts: 4
Rep Power: 7
w.chaabouni is on a distinguished road
Hello everyone,

I am running a simulation based on the tutorial "/tutorials/multiphase/interFoam/laminar/waveExampleStokesI". When I run simulation, I have a similar ERROR


/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1812 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1812 OPENFOAM=1812
Arch : "LSB;label=32;scalar=64"
Exec : interFoam -dry-run-write
Date : May 07 2019
Time : 14:03:22
Host : default
PID : 1007
I/O : uncollated
Case : /home/ofuser/workingDir/OpenFoam/tests/case5
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Operating in 'dry-run' mode: case will run for 1 time step. All checks assumed OK on a clean exit
Selecting simplified mesh model staticFvMesh
Creating simplified mesh using "/home/ofuser/workingDir/OpenFoam/tests/case5/constant/polyMesh"
Mesh bounds: (0 0 0) (10 0.04 30)

PIMPLE: Operating solver in PISO mode

Reading field p_rgh

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
Selecting laminar stress model Stokes

Reading g

Reading hRef
Calculating field g.h

No MRF models present

No finite volume options present
DICPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Courant Number mean: 0 max: 0

Starting time loop

Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
Time = 0.01

PIMPLE: iteration 1
Selecting waveModel StokesI
#0 Foam::error:rintStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libc.so.6
#3 Foam::waveModel::initialiseGeometry() at ??:?
#4 Foam::waveModel::readDict(Foam::dictionary const&) at ??:?
#5 Foam::waveModels::waveGenerationModel::readDict(Fo am::dictionary const&) at ??:?
#6 Foam::waveModels::irregularWaveModel::readDict(Foa m::dictionary const&) at ??:?
#7 Foam::waveModels::regularWaveModel::readDict(Foam: :dictionary const&) at ??:?
#8 Foam::waveModels::StokesI::readDict(Foam::dictiona ry const&) at ??:?
#9 Foam::waveModels::StokesI::StokesI(Foam::dictionar y const&, Foam::fvMesh const&, Foam:olyPatch const&, bool) at ??:?
#10 Foam::waveModel::addpatchConstructorToTable<Foam:: waveModels::StokesI>::New(Foam::dictionary const&, Foam::fvMesh const&, Foam:olyPatch const&) at ??:?
#11 Foam::waveModel::New(Foam::word const&, Foam::fvMesh const&, Foam:olyPatch const&) at ??:?
#12 Foam::waveModel::lookupOrCreate(Foam:olyPatch const&, Foam::fvMesh const&, Foam::word const&) at ??:?
#13 Foam::waveAlphaFvPatchScalarField::updateCoeffs() at ??:?
#14 Foam::fvPatchField<double>::evaluate(Foam::UPstrea m::commsTypes) at ??:?
#15 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() at ??:?
#16 ? at interFoam.C:?
#17 ? at ??:?
#18 __libc_start_main in /lib64/libc.so.6
#19 ? at ??:?
Floating point exception




Can anyone help me with it please?
w.chaabouni is offline   Reply With Quote

Reply


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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Benchmarking interFOAM -- problems... einatlev OpenFOAM Running, Solving & CFD 6 March 19, 2015 10:16
interFoam simulation yields inconsistent results for alpha1 surface Ralinus OpenFOAM Running, Solving & CFD 8 January 13, 2014 08:54
Pressure convergence problems with sloped bottom in interFoam gradylemoine OpenFOAM Running, Solving & CFD 0 November 18, 2013 18:33
Problems with interFoam usage vrecha OpenFOAM Running, Solving & CFD 4 January 5, 2008 03:34
Problems starting new case interFoam billy OpenFOAM Running, Solving & CFD 3 June 21, 2006 10:18


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