[bentkj]

I would really appreciate it if anyone could shed some information on this problem that I'm facing where I encounter non-physical behavior at the boundaries of my domain due to sinusoidal oscillation at the inlet.

Context:

I'm trying to perform a forced pitch oscillation of a wing where the angle of attack is sinusoidal at the inlet resulting in the wing undergoing pitch oscillation.
Here is my grid (polyMesh file here) and its checkMesh details:


The mesh is relatively coarse, but of good quality as I'm trying to get something running first. Here is my checkMesh output:

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
Build  : 6-6257b17a4cf8
Exec   : checkMesh
Date   : Jan 22 2019
Time   : 11:02:10
Host   : "bentkj"
PID    : 12927
I/O    : uncollated
Case   : /home/bentkj/Desktop/FPO_Re1.8M_10deg_NACA0012_6x36ft_SqTips_SharpTE_VeryCoarse
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

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

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           485178
    faces:            1421163
    internal faces:   1387026
    cells:            468075
    faces per cell:   5.99944
    boundary patches: 5
    point zones:      0
    face zones:       1
    cell zones:       1

Overall number of cells of each type:
    hexahedra:     467814
    prisms:        261
    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                  
    NACA0012            1695     1725     ok (non-closed singly connected)  
    SYM                 8784     8957     ok (non-closed singly connected)  
    FARFIELD            8871     9007     ok (non-closed singly connected)  
    OUTLET              5088     5238     ok (non-closed singly connected)  
    INLET               9699     9936     ok (non-closed singly connected)  

Checking geometry...
    Overall domain bounding box (-26.8371 -27.4 -27.4) (36.5 0 27.4)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (2.27861e-15 -3.89001e-16 -7.70399e-17) OK.
    Max cell openness = 4.17414e-16 OK.
    Max aspect ratio = 136.035 OK.
    Minimum face area = 0.000160401. Maximum face area = 4.88289.  Face area magnitudes OK.
    Min volume = 4.54879e-05. Max volume = 3.68761.  Total volume = 86323.4.  Cell volumes OK.
    Mesh non-orthogonality Max: 48.1605 average: 9.37349
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.935538 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

For pitching oscillation, a constant freestream velocity magnitude is maintained but with varying angle of attack.
Therefore, I have written a python script to output u and v velocity components as a function of time for my inlet as a .csv file to be read.
An example of the first few lines of my .csv file:

time,u,v,w
0.0,14.155626641797479,2.496018905784457,0
0.00025,14.15542130460082,2.4971831509229037,0
0.0005,14.155215871695166,2.4983473789105717,0

This inlet condition is read with theuniformFixedValue boundary condition in the 0/U file as attached with the other relevant boundary conditions
(the comments contained are other options I've tried but I'm faced with the same problem).

INLET
{
        type uniformFixedValue;
        uniformValue
        {
            type csvFile;
            nHeaderLine 1; // number of header lines
            refColumn 0; // time column index
            componentColumns (1 3 2); // data column index
            separator ","; // optional (defaults to ",")
            mergeSeparators no; // merge multiple separators
            file "$FOAM_CASE/0/sineAlpha.csv";
        }
}

This is then run with the pisoFoam solver.
An example of my log.pisoFoam output is typical, and is as such:

Time = 0.9275

Courant Number mean: 0.00723135 max: 0.569428
smoothSolver:  Solving for Ux, Initial residual = 0.000446676, Final residual = 5.48794e-11, No Iterations 2
smoothSolver:  Solving for Uy, Initial residual = 9.264e-05, Final residual = 4.35567e-08, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 0.000602655, Final residual = 3.40641e-11, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.00192879, Final residual = 9.81297e-07, No Iterations 17
time step continuity errors : sum local = 3.18157e-13, global = 3.5438e-14, cumulative = -9.26395e-10
GAMG:  Solving for p, Initial residual = 3.12659e-05, Final residual = 8.22712e-07, No Iterations 7
time step continuity errors : sum local = 2.66708e-13, global = 4.71905e-14, cumulative = -9.26348e-10
GAMG:  Solving for p, Initial residual = 7.78922e-06, Final residual = 7.65518e-07, No Iterations 3

The attached are the fvSolution and fvSchemes of my case. Note that the tight tolerances are just a result of my own troubleshooting.

Problem:
Monitoring the solution shows non-physical results occurring at both the upper and lower boundaries of the domain,
and the solution sometimes diverges if it's run long enough (about 4 pitch cycles) As pictured:


The contours seem incorrect and are not representative of freestream conditions.
The upper and lower patches are also of the inlet type (polyMesh file linked above) and from my understanding, I do not see any reason why this would not work.
From my own experimenting, this non-physical behavior does not seem to occur when a fixedValue inlet boundary condition is used!

Could someone please enlighten me on why this is occurring and what is wrong with my methodology?
I would greatly appreciate it if I could get hints, or an alternative approach to overcome this problem.
I have been stuck on this for weeks now and conducting this forced pitching simulation is vital progressing in my work.

Thank you.

[sandrobrad]

Originally Posted by bentkj

I would really appreciate it if anyone could shed some information on this problem that I'm facing where I encounter non-physical behavior at the boundaries of my domain due to sinusoidal oscillation at the inlet.

Context:

I'm trying to perform a forced pitch oscillation of a wing where the angle of attack is sinusoidal at the inlet resulting in the wing undergoing pitch oscillation.
Here is my grid (polyMesh file here) and its checkMesh details:


The mesh is relatively coarse, but of good quality as I'm trying to get something running first. Here is my checkMesh output:

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
Build  : 6-6257b17a4cf8
Exec   : checkMesh
Date   : Jan 22 2019
Time   : 11:02:10
Host   : "bentkj"
PID    : 12927
I/O    : uncollated
Case   : /home/bentkj/Desktop/FPO_Re1.8M_10deg_NACA0012_6x36ft_SqTips_SharpTE_VeryCoarse
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

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

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           485178
    faces:            1421163
    internal faces:   1387026
    cells:            468075
    faces per cell:   5.99944
    boundary patches: 5
    point zones:      0
    face zones:       1
    cell zones:       1

Overall number of cells of each type:
    hexahedra:     467814
    prisms:        261
    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                  
    NACA0012            1695     1725     ok (non-closed singly connected)  
    SYM                 8784     8957     ok (non-closed singly connected)  
    FARFIELD            8871     9007     ok (non-closed singly connected)  
    OUTLET              5088     5238     ok (non-closed singly connected)  
    INLET               9699     9936     ok (non-closed singly connected)  

Checking geometry...
    Overall domain bounding box (-26.8371 -27.4 -27.4) (36.5 0 27.4)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (2.27861e-15 -3.89001e-16 -7.70399e-17) OK.
    Max cell openness = 4.17414e-16 OK.
    Max aspect ratio = 136.035 OK.
    Minimum face area = 0.000160401. Maximum face area = 4.88289.  Face area magnitudes OK.
    Min volume = 4.54879e-05. Max volume = 3.68761.  Total volume = 86323.4.  Cell volumes OK.
    Mesh non-orthogonality Max: 48.1605 average: 9.37349
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.935538 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

For pitching oscillation, a constant freestream velocity magnitude is maintained but with varying angle of attack.
Therefore, I have written a python script to output u and v velocity components as a function of time for my inlet as a .csv file to be read.
An example of the first few lines of my .csv file:

time,u,v,w
0.0,14.155626641797479,2.496018905784457,0
0.00025,14.15542130460082,2.4971831509229037,0
0.0005,14.155215871695166,2.4983473789105717,0

This inlet condition is read with theuniformFixedValue boundary condition in the 0/U file as attached with the other relevant boundary conditions
(the comments contained are other options I've tried but I'm faced with the same problem).

INLET
{
        type uniformFixedValue;
        uniformValue
        {
            type csvFile;
            nHeaderLine 1; // number of header lines
            refColumn 0; // time column index
            componentColumns (1 3 2); // data column index
            separator ","; // optional (defaults to ",")
            mergeSeparators no; // merge multiple separators
            file "$FOAM_CASE/0/sineAlpha.csv";
        }
}

This is then run with the pisoFoam solver.
An example of my log.pisoFoam output is typical, and is as such:

Time = 0.9275

Courant Number mean: 0.00723135 max: 0.569428
smoothSolver:  Solving for Ux, Initial residual = 0.000446676, Final residual = 5.48794e-11, No Iterations 2
smoothSolver:  Solving for Uy, Initial residual = 9.264e-05, Final residual = 4.35567e-08, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 0.000602655, Final residual = 3.40641e-11, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.00192879, Final residual = 9.81297e-07, No Iterations 17
time step continuity errors : sum local = 3.18157e-13, global = 3.5438e-14, cumulative = -9.26395e-10
GAMG:  Solving for p, Initial residual = 3.12659e-05, Final residual = 8.22712e-07, No Iterations 7
time step continuity errors : sum local = 2.66708e-13, global = 4.71905e-14, cumulative = -9.26348e-10
GAMG:  Solving for p, Initial residual = 7.78922e-06, Final residual = 7.65518e-07, No Iterations 3

The attached are the fvSolution and fvSchemes of my case. Note that the tight tolerances are just a result of my own troubleshooting.

Problem:
Monitoring the solution shows non-physical results occurring at both the upper and lower boundaries of the domain,
and the solution sometimes diverges if it's run long enough (about 4 pitch cycles) As pictured:


The contours seem incorrect and are not representative of freestream conditions.
The upper and lower patches are also of the inlet type (polyMesh file linked above) and from my understanding, I do not see any reason why this would not work.
From my own experimenting, this non-physical behavior does not seem to occur when a fixedValue inlet boundary condition is used!

Could someone please enlighten me on why this is occurring and what is wrong with my methodology?
I would greatly appreciate it if I could get hints, or an alternative approach to overcome this problem.
I have been stuck on this for weeks now and conducting this forced pitching simulation is vital progressing in my work.

Thank you.

Hi Ben,
First of all I have to say that I've followed the same strategy and I got the same results. As a result I have the same issue.
So , did you eventually get physical results using this strategy ?
If not, how did you get physical results ? using dynamic meshes?
Currently I am stuck in this point and I don't know if I rely on my cl, alpha results or switch to the dynamic mesh strategy.
Thats all for the moment. Thank you in advance and I'm so eager to see what you've done eventually.
Cheers