[ss32]

I've successfully run the 2D airfoil and am using it as a framework for importing another airfoil with a C-grid mesh that was generated in Pointwise. The mesh imports fine and I am able to view it, but when solving for the initial p value I get crazy big errors that lead to nan residuals and a floating point memory error. My Ux & Uy residuals are better, but still on the order of 10 so I'm not sure why they aren't converging either.

Steps taken so far:
1. Decreased timestep and run time
2. Increased freestream velocity
3. Decreased freestream velocity
4. Decreased domain size
5. Tried an O-grid


None of this seems to have any effect and I'm not sure what's causing the issue. I'm assuming it's something in my initial conditions as it looks like the solution is diverging but I have changed everything I can think of with no luck. I just started using OpenFoam yesterday so this is all a little new to me and any help is appreciated.


Run log:

SIMPLE: convergence criteria
    field p     tolerance 1e-05
    field U     tolerance 1e-05
    field nuTilda     tolerance 1e-05

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model SpalartAllmaras
Selecting patchDistMethod meshWave
SpalartAllmarasCoeffs
{
    sigmaNut        0.66666;
    kappa           0.41;
    Cb1             0.1355;
    Cb2             0.622;
    Cw2             0.3;
    Cw3             2;
    Cv1             7.1;
    Cs              0.3;
}

No MRF models present

No finite volume options present


Starting time loop

Time = 0.0001

smoothSolver:  Solving for Ux, Initial residual = 1, Final residual = 334.464, No Iterations 1000
smoothSolver:  Solving for Uy, Initial residual = 1, Final residual = 1.65567, No Iterations 1000
GAMG:  Solving for p, Initial residual = 1, Final residual = 3.50073e+66, No Iterations 1000
time step continuity errors : sum local = 9.00991e+61, global = 6.21187e+44, cumulative = 6.21187e+44
smoothSolver:  Solving for nuTilda, Initial residual = 1, Final residual = nan, No Iterations 1000
ExecutionTime = 2.1 s  ClockTime = 3 s



--> FOAM FATAL IO ERROR: 
wrong token type - expected Scalar, found on line 0 the word 'nan'

file: /home/scott/OpenFOAM/scott-v3.0+/run/tutorials/incompressible/simpleFoam/glauert/system/data.solverPerformance.nuTilda at line 0.

    From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&)
    in file lnInclude/Scalar.C at line 93.

FOAM exiting

[ppendota]

Hi,

I guess these ideas might help you: 1. check if you adequate mesh resolution.
2. Try increasing viscosity by a large value
3. What solver are you using? - get a steady state solution to initialize your unsteady solution.

Thanks.

Prem

[ss32]

Originally Posted by ppendota

Hi,

I guess these ideas might help you: 1. check if you adequate mesh resolution.
2. Try increasing viscosity by a large value
3. What solver are you using? - get a steady state solution to initialize your unsteady solution.

Thanks.

Prem

1. I have a high mesh resolution, higher than the standard 2D airfoil example.
2. I ramped up viscosity from 1e-3 to 100 and got the same results
3. I am using simpleFoam solver using RAS SpalartAllmaras

Literally the only thing that has changed from the 2D airfoil is the grid. Boundary conditions are:

Sides - empty
Airfoil - wall
Top/bottom/front/back - patch

edit: I see now that the 2D airfoil really is 2d, and my grid is 1 block deep, so that's possibly the cause. I will try a 2D mesh and see if it works.

[tas38]

There definitely appears to be an issue with either the mesh or the boundary conditions as both the momentum and pressure correction equations have very high residuals following the first iteration. Momentum residuals should definitely be driven down to small values after just a few iterations.

I would suggest running checkMesh for errors. Barring any errors from checkMesh, you should elaborate a bit more on the boundary conditions. But given that you ran a previous case successfully, I think the bcs are less likely the source of the non-convergence.

Also, a 2d case in OpenFOAM does require a cells of finite depth in the third, un-resolved direction.

[ss32]

Originally Posted by tas38

There definitely appears to be an issue with either the mesh or the boundary conditions as both the momentum and pressure correction equations have very high residuals following the first iteration. Momentum residuals should definitely be driven down to small values after just a few iterations.

I would suggest running checkMesh for errors. Barring any errors from checkMesh, you should elaborate a bit more on the boundary conditions. But given that you ran a previous case successfully, I think the bcs are less likely the source of the non-convergence.

Also, a 2d case in OpenFOAM does require a cells of finite depth in the third, un-resolved direction.

checkMesh came back good

bash-4.1$ checkMesh
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v3.0+                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : v3.0+-e941ee6c15e9
Exec   : checkMesh
Date   : Apr 10 2016
Time   : 15:19:31
Host   : "7e693b17c8c8"
PID    : 292
Case   : /home/user/OpenFOAM/user-v3.0+/run/tutorials/incompressible/simpleFoam/glauert
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

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

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           40700
    internal points:  0
    faces:            80350
    internal faces:   39650
    cells:            20000
    faces per cell:   6
    boundary patches: 3
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     20000
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
    Patch               Faces    Points   Surface topology                  
    airfoil             200      400      ok (non-closed singly connected)  
    farfield            500      1000     ok (non-closed singly connected)  
    sides               40000    40700    ok (non-closed singly connected)  

Checking geometry...
    Overall domain bounding box (-8.59397 -12.0671 0) (15 12.0671 1)
    Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
    Mesh has 2 solution (non-empty) directions (1 1 0)
    All edges aligned with or perpendicular to non-empty directions.
    Boundary openness (-2.05708e-17 -9.05116e-18 -2.71159e-15) OK.
    Max cell openness = 9.47623e-16 OK.
    Max aspect ratio = 67.3456 OK.
    Minimum face area = 8.49192e-06. Maximum face area = 1.17181.  Face area magnitudes OK.
    Min volume = 8.49192e-06. Max volume = 0.608617.  Total volume = 496.902.  Cell volumes OK.
    Mesh non-orthogonality Max: 40.7387 average: 2.66617
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.777325 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

In looking at the 2D airfoil example it appears to be flat, but I think the depthwise extrusion is just thinner in that case.

More on my boundary conditions: The strip going around the C-grid is set to patch, the airfoil itself is a wall, and the sides are empty. You can see it in the first image (ignore the grey patches, those are rendering artifacts). Also, there is a thin strip at the trailing edge of the airfoil that goes to the boundary where the C closes that is set to patch as well. It's visible in the second image. I followed the boundary conditions in the video - here - and then followed the same guy's C-grid tutorial, adapting the boundary conditions from the first video.

[tas38]

Originally Posted by ss32

In looking at the 2D airfoil example it appears to be flat, but I think the depthwise extrusion is just thinner in that case.

This is rather interesting. You may want to drastically reduce the depth of the model. I noticed difficulty getting a converged solution for 2d journal bearing profiles if the depth was not set to quite a 'small' value.

[ss32]

Originally Posted by tas38

This is rather interesting. You may want to drastically reduce the depth of the model. I noticed difficulty getting a converged solution for 2d journal bearing profiles if the depth was not set to quite a 'small' value.

Compared to mine, it's almost not even there; you can barely make out surface #3. It's also worth noting that all of the BC in the 2d example are patches.

edit: Maybe not. the polyMesh/boundary file shows them as different types but paraFoam does not...weird.

FoamFile
{
    version     2.0;
    format      ascii;
    class       polyBoundaryMesh;
    object      boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
4
(
inlet
{
    type patch;
    physicalType inlet;
    nFaces 134;
    startFace 21254;
}

outlet
{
    type patch;
    physicalType outlet;
    nFaces 160;
    startFace 21388;
}

walls
{
    type wall;
    physicalType wall;
    nFaces 78;
    startFace 21548;
}

frontAndBack
{
    type empty;
    physicalType empty;
    nFaces 21440;
    startFace 21626;
}
)

// ************************************************************************* //

I'll have to check the settings in Pointwise to see if I can change the extrusion depth but I know I only had it run 1 step. Thanks for the help!

[tas38]

Good luck. Please post an update if reducing the model depth solves the issue.

[ss32]

Originally Posted by tas38

Good luck. Please post an update if reducing the model depth solves the issue.

It did not. I tried extrusion depths of 0.01 and 0.1, where my first one was a step of 1. Now the residuals are even worse. I'm wondering if I need an inlet and oulet like the 2d airfoil example. Right now I'm only providing it a freestream velocity via the internal field. Could that be the issue?

edit: And if that is the issue, how do you provide an inlet on a curved surface?

0.1

Starting time loop

Time = 0.0001

smoothSolver:  Solving for Ux, Initial residual = 1, Final residual = 114.385, No Iterations 1000
smoothSolver:  Solving for Uy, Initial residual = 1, Final residual = 3.23689, No Iterations 1000
GAMG:  Solving for p, Initial residual = 1, Final residual = nan, No Iterations 1000
time step continuity errors : sum local = nan, global = -nan, cumulative = -nan
smoothSolver:  Solving for nuTilda, Initial residual = nan, Final residual = nan, No Iterations 1000
ExecutionTime = 1.59 s  ClockTime = 1 s



--> FOAM FATAL IO ERROR: 
wrong token type - expected Scalar, found on line 0 the word 'nan'

file: /home/user/OpenFOAM/user-v3.0+/run/tutorials/incompressible/simpleFoam/glauert/system/data.solverPerformance.p at line 0.

    From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&)
    in file lnInclude/Scalar.C at line 93.

FOAM exiting

0.01

Starting time loop

Time = 0.0001

smoothSolver:  Solving for Ux, Initial residual = 1, Final residual = 3.95588e+147, No Iterations 1000
smoothSolver:  Solving for Uy, Initial residual = 1, Final residual = 4.91147e+145, No Iterations 1000
GAMG:  Solving for p, Initial residual = 1, Final residual = nan, No Iterations 1000
time step continuity errors : sum local = nan, global = -nan, cumulative = -nan
smoothSolver:  Solving for nuTilda, Initial residual = nan, Final residual = nan, No Iterations 1000
ExecutionTime = 1.95 s  ClockTime = 2 s



--> FOAM FATAL IO ERROR: 
wrong token type - expected Scalar, found on line 0 the word 'nan'

file: /home/user/OpenFOAM/user-v3.0+/run/tutorials/incompressible/simpleFoam/glauert/system/data.solverPerformance.p at line 0.

    From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&)
    in file lnInclude/Scalar.C at line 93.

FOAM exiting

[tas38]

I don't believe you explicitly need to have 'inlet' and 'outlet'. You can just set all of external boundaries (inclusive of the curved patch) type 'freestream' with 'freestreamValue' of the
for uniform (100.0 0.0 0.0) where you would set the velocity to the same as the internal field.

These boundaries would then be of type 'freestreampressure' in the 'P' file.

[ss32]

Originally Posted by tas38

I don't believe you explicitly need to have 'inlet' and 'outlet'. You can just set all of external boundaries (inclusive of the curved patch) type 'freestream' with 'freestreamValue' of the
for uniform (100.0 0.0 0.0) where you would set the velocity to the same as the internal field.

Ok yeah, that's how I have them set.

U file:

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (15.0 0 0);

boundaryField
{
    airfoil
    {
        type            fixedValue;
        value               uniform (0 0 0);
    }

    farfield
    {
        type            freestream;
        freestreamValue uniform (15.0 0 0);
    }

    sides
    {
        type            empty;
        
    }

}

And the p file:

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    airfoil
    {
        type            zeroGradient;
    }

    farfield
    {
        type            freestreamPressure;
    }

    sides
    {
        type            empty;
    }
}

nut:

dimensions      [0 2 -1 0 0 0 0];

internalField   uniform 0.14;

boundaryField
{
    airfoil
    {
        type            nutUSpaldingWallFunction;
        value           uniform 0;
    }

    farfield
    {
        type            freestream;
        freestreamValue uniform 0.14;
    }

    sides
    {
        type            empty;
        value           uniform 0;
    }

}

nuTilda

dimensions      [0 2 -1 0 0 0 0];

internalField   uniform 0.14;

boundaryField
{
    airfoil
    {
        type            fixedValue;
        value            uniform 0;
    }

    farfield
    {
        type            freestream;
        freestreamValue uniform 0.14;
    }

    sides
    {
        type            empty;

    }

 }

[tas38]

Ok.

A couple simple things to try...
1. Run potentialFoam to initialize the velocity field. Does the velocity vector field look ok?
2. Run your viscous case as laminar. I don't think this will help as the divergence occurs immediately, but it is worth a try and will simplify the subsequent diagnosis of the issue. Note that you should run with a very low velocity or high viscosity such that laminar case has potential to converge.

[ss32]

Originally Posted by tas38

Ok.

A couple simple things to try...
1. Run potentialFoam to initialize the velocity field. Does the velocity vector field look ok?
2. Run your viscous case as laminar. I don't think this will help as the divergence occurs immediately, but it is worth a try and will simplify the subsequent diagnosis of the issue. Note that you should run with a very low velocity or high viscosity such that laminar case has potential to converge.

Working on these. After adding this to the end of system/fvSolution

potentialFlow
{
    nNonOrthogonalCorrectors 10;
    PhiRefCell 0; 
    PhiRefValue 0; 
}

I'm getting an error telling me that Phi isn't defined in the dictionary. Where does that need to be added?

And to run this as laminar do I just set turblence to "off" in constant/turbulenceProperties?

[tas38]

In fvSolution file...

potentialFlow
{
    nNonOrthogonalCorrectors 10;
}

I think this will get rid of the missing Phi error.

And yes, just set turbulence to 'off'. I also set RASmodel to 'laminar' but I think this is redundant.

[ss32]

I tried running with just

nNonOrthogonalCorrectors 10;

and got an error:

Unable to set reference cell for field Phi
    Please supply either PhiRefCell or PhiRefPoint

So I added them and that left me with the error I posted above. Also, running with turbulence off yielded the same results, giant residuals, and changing RASModel to laminar threw an error because laminar is not a valid model type. I'm not sure setting turbulence to "off" did the trick so I'm looking into that some more.

[tas38]

In fvSchemes under fluxRequired is phi listed? This may be why it throws the error.

[ss32]

fluxRequired isn't even there.

fvSchemes

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v3.0+                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         Gauss linear;
}

divSchemes
{
    default         none;
    div(phi,U)      bounded Gauss linearUpwind grad(U);
    div(phi,nuTilda) bounded Gauss linearUpwind grad(nuTilda);
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

wallDist
{
    method meshWave;
}


// ************************************************************************* //

And fvSolution

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v3.0+                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    p
    {
        solver          GAMG;
        tolerance       1e-06;
        relTol          0.1;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    U
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        nSweeps         2;
        tolerance       1e-08;
        relTol          0.1;
    }

    nuTilda
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        nSweeps         2;
        tolerance       1e-08;
        relTol          0.1;
    }
}

SIMPLE
{
    nNonOrthogonalCorrectors 0;
    pRefCell        0;
    pRefValue       0;

    residualControl
    {
        p               1e-5;
        U               1e-5;
        nuTilda         1e-5;
    }
}

relaxationFactors
{
    fields
    {
        p               0.3;
    }
    equations
    {
        U               0.7;
        nuTilda         0.7;
    }
}
potentialFlow
{
    nNonOrthogonalCorrectors 10;
    PhiRefCell 0; 
    PhiRefValue 0; 
}

// ************************************************************************* //

[tas38]

error says to supply PhiRefCell or PhiRefPoint

I realize you are working with a newer version of OpenFOAM (3.0?). I did not realize there were some many changes since 2.3 which may affect such a relatively simple simulation. This is why it is throwing errors that I am unaccustomed to seeing.

[ss32]

Good catch. I tried running it twice, both with one of the variables, and got the same results. Glad to know this seems more difficult than it should be and it's not just because I'm new to OpenFoam

[tas38]

If you post an external link of your full case directory, I can quickly try to run in 2.3.0 and see what errors it throws.

I think this may be the quickest way to track down the issue.