[cyln]

Hello,

I want to know how I can define an interface for a non-conformal mesh in my flow domain in OF. I have a complex geometry/body and I mesh it using unstructured grid. However, I created a zone in the wake of my body that has a structured mesh. I am using ICEM as a mesh generator and I import my mesh to OF using fluentMeshToFoam.

Can anybody briefly explain me the steps to define a non-conformal interface in openfoam? Or maybe suggest a tutorial?


Cheers,
Cyln

[mAlletto]

You can Google for ami (arbitary MESh interphase) and openfoam. You can find a lot about this topic. The workflow is rather simple. Make the two meshes. Delfine the patches you want to couple as ami. Merge the meshes with the utility mergeMesh.

[cyln]

Hello Michael, thanks a lot for your reply.

I have already used cyclicAMI as a rotational periodic BC before. However, in my current simulation, I do not to how to implement it since it is not rotational or translational. I attached a simple 2D schematic to explain my problem. It is quite simple. As I said, my flow domain has both tetrahedral and hexahedral grid. In tetrahedral mesh, I defined the interface as INTERFACE_T whereas, in hexa mesh, I defined the interface as INTERFACE_H. My flow regions are then FLUID1 and FLUID2, respectively.

I already merged two meshes in ICEM when I opened them together, however, the interface is non-conformal.

Before saving the mesh as a fluent mesh in ICEM, I did set the boundary conditions as well (i.e. INTERFACE_T = interface, FLUID1 = fluid, ...)

After using fluentMeshToFoam, I am not sure if I should use mergeMesh ??
Moreover, my flow domain has two flow regions: FLUID1 (tetra) and FLUID2 (hexa).

1- How should I set my boundary conditions in 0/U and 0/p since I have two flow regions (FLUID1 and FLUID2)?
2- How should my boundary file look like in constant/polyMesh/boundary? (for the interfaces). How do I couple INTERFACE_T and INTERFACE_H?

[mAlletto]

the boundary file has to look like:

fluid1
{
type cyclicAMI;
inGroups 1(cyclicAMI);
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch fluid2;
}

fluid2
{
type cyclicAMI;
inGroups 1(cyclicAMI);
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch fluid1;
}


the boundary conditions have to look like:

fluid2{
type cyclicAMI;
value $internalField;
}

fluid1{
type cyclicAMI;
value $internalField;
}

[cyln]

Hello Micheal,

I did set the boundary conditions as below:

0/p

INTERFACET2
{
type     cyclicAMI;
}

INTERFACE2
{
type     cyclicAMI;
}

0/U

INTERFACET2
{
type     cyclicAMI;
value    $internalField;
}

INTERFACE2
{
type     cyclicAMI;
value    $internalField;
}

and my boundary file looks like:

    INTERFACET2
    {
        type            cyclicAMI;
        inGroups        1(cyclicAMI);
        nFaces          159500;
        startFace       53173769;
        matchTolerance  0.001;
        transform       noOrdering;
        neighbourPatch  INTERFACE2;
    }
    INTERFACE2
    {
        type            cyclicAMI;
        inGroups        1(cyclicAMI);
        nFaces          234023;
        startFace       53333269;
        matchTolerance  0.001;
        transform       noOrdering;
        neighbourPatch  INTERFACET2;
    }

After 10 time steps, my simulation diverges. Can you see any mistake with my boundary conditions? It is due to interface because my simulation was running fine with one domain meshed with an unstructured grid.


Cyln

[mAlletto]

Form a first look it seems find. Apparat that in the boundary condition file you have INTERFACE and in the boundery file INTERFACE2. Do you have big cell jumps over the ami.

[cyln]

It was just a typo I wrote accidentally here. In the simulation, it is set up correctly as INTERFACE2.

As for big cell jumps, I suppose you mean from hexa interface to tetra interface. If so, there are definitely big cell jumps. It is also because hexa cells have aspect ratio values between 100-200 at the interface while my tetra cells at the interface are very coarse, especially closer to the outlet section.

I can further increase my tetra mesh resolution at the interface. How can I check or make sure cell jumps do not cause any problem? Is there any way to set the element size at the interface for hexa and tetra cells since my inerface is non-comformal?

I should also add this. Even though my simulation diverges after 10 time steps (I say this by looking at my flow parameters such as velocity and pressure), my residuals still seem to converge nicely. This is very weird. I did not continue my simulation after that, but the residuals may start diverge later too if one keeps it running further.

[mAlletto]

Usually the cell volume jumps should not be Mord than 10 for a good quality solution. The cell size can be modiyfied by the mesher.

Did you check where in the domain the divergence starts? You have to look for high velocities a.s.o. this may give a hint what's Göring wrong

[cyln]

Hi Michael, I think cell jumps was the problem. My simulation has been running without a problem for a while. Thanks a lot for your help.

Cheers

[mAlletto]

You're welcome. Glade to be oft some help.

[cyln]

Hello Michael,

My laminar simulation has been running without ant issues and I have completed the laminar simulation.

However, now I am running my simulation turbulent with kOmegaSST model. I used this model for the same case with fully unstructured grid and it was running without any problem. Remember, for a certain purpose, my current mesh is a combination of unstructured and structured grids. At the interface of them, I am using cyclicAMI (noOrdering) BC. In the case with cyclicAMI, I am having a floating point error and my simulation is not converging at all.

This msut be due to interface setup for the turbulence parameters (k, omega, nut) as the simulation was running okay without any interface. My BCs are as below. Any suggestion to solve my problem?

0/k

internalField   uniform 1e-6; 


boundaryField
{

    FARFIELD
    {
        type fixedValue;
        value uniform 1e-6;
    }

    BODY
    {
        type           fixedValue;
        value          uniform 0.0;
    }

    OUTLET
    {
        type            zeroGradient;
    }

                INTEROUTT2
    {
        type cyclicAMI;
    }

    INTEROUT2
    {
        type cyclicAMI;
    }

    INTERFACET2
    {
        type cyclicAMI;
    }

    INTERFACE2
    {
        type cyclicAMI;
    }


}

0/omega

internalField   uniform 0.55 ; 


boundaryField
{

    FARFIELD
    {
        type fixedValue;
        value uniform 0.55;     //  
    }

    BODY
    {
        type           fixedValue;
        value          uniform 241632653;
    }

    OUTLET
    {
        type            zeroGradient;

        }

        INTEROUTT2
    {
        type cyclicAMI;
    }

    INTEROUT2
    {
        type cyclicAMI;
    }

    INTERFACET2
    {
        type cyclicAMI;
    }

    INTERFACE2
    {
        type cyclicAMI;
    }



}

0/nut

internalField   uniform 0;

//OF22

boundaryField
{

    FARFIELD
    {
      type            calculated;
      value           uniform 0;
    }

    OUTLET
    {
         type            calculated;
        value           uniform 0;
    }

    BODY
    {
        type            fixedValue; //nutkWallFunction;
        value           uniform 0;
    }

                INTEROUTT2
    {
        type cyclicAMI;
    }

    INTEROUT2
    {
        type cyclicAMI;
    }

    INTERFACET2
    {
        type cyclicAMI;
    }

    INTERFACE2
    {
        type cyclicAMI;
    }


}

[mAlletto]

Floating point exception is usually division by zero. In which equation are you getting the floating point exception?

I wonder why you're using so high values of omega at the BODY boundary condition

[cyln]

I cannot really see exactly in which equation I am getting this division by zero error. So, below is the important parts from my log file. What I can see is the floating point error is given after the start of fieldAverage calculation. Due to the divergence, the numbers are so big that, it may be giving this error due to division of summed property values by a small integer (number of time steps).

Also, My simulation runs a couple of time steps before giving this error. My simulation diverges right after calculating the turbulence parameters as I am solving the turbulence parameters in the last outer loop iteration. You can see this in attached residual plot.

As for the omega value at the BODY wall, it is calculated using: omega = 60 nu /(0.075* y_1^2). I do not think this is the problem because, as I said, without an interface, the turbulent simulation has been running without any errors

smoothSolver:  Iteration 220 residual = 9.72116e-07
smoothSolver:  Solving for k, Initial residual = 0.655856, Final residual = 9.72116e-07, No Iterations 220
bounding k, min: -2.4925e-05 max: 0.000510477 average: 6.39755e-07
PIMPLE: not converged within 35 iterations
ExecutionTime = 39921.2 s  ClockTime = 39981 s

forceCoeffs forceCoefficients write:
    Cm    = -1.1233e+167
    Cd    = 1.58672e+168
    Cl    = -4.13146e+164
    Cl(f) = -1.12536e+167
    Cl(r) = 1.12123e+167

fieldAverage fieldAverage1 write:
    Calculating averages
[19] #0  Foam::error::printStack(Foam::Ostream&)[21] #0  Foam::error::printStack(Foam::Ostream&)[22] #0  Foam::error::printStack(Foam::Ostream&)[23] #0  Foam::error::printStack(Foam::Ostream&)[24] #0  Foam::error::printStack(Foam::Ostream&)[25] #0  Foam::error::printStack(Foam::Ostream&)[26] #0  Foam::error::printStack(Foam::Ostream&)[27] #0  Foam::error::printStack(Foam::Ostream&)[28] #0  Foam::error::printStack(Foam::Ostream&)[29] #0  Foam::error::printStack(Foam::Ostream&)[0] #0  Foam::error::printStack(Foam::Ostream&)[1] #0  Foam::error::printStack(Foam::Ostream&)[2] #0  Foam::error::printStack(Foam::Ostream&)[3] #0  Foam::error::printStack(Foam::Ostream&)[4] #0  Foam::error::printStack(Foam::Ostream&)[5] #0  Foam::error::printStack(Foam::Ostream&)[6] #0  Foam::error::printStack(Foam::Ostream&)[7] #0  Foam::error::printStack(Foam::Ostream&)[8] #0  Foam::error::printStack(Foam::Ostream&)[9] #0  Foam::error::printStack(Foam::Ostream&)[10] #0  Foam::error::printStack(Foam::Ostream&)[11] #0  Foam::error::printStack(Foam::Ostream&)[12] #0  Foam::error::printStack(Foam::Ostream&)[13] #0  Foam::error::printStack(Foam::Ostream&)[14] #0  Foam::error::printStack(Foam::Ostream&)[15] #0  Foam::error::printStack(Foam::Ostream&)[16] #0  Foam::error::printStack(Foam::Ostream&)[17] #0  Foam::error::printStack(Foam::Ostream&)[18] #0  Foam::error::printStack(Foam::Ostream&)[20] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[5] #1  Foam::sigFpe::sigHandler(int) at ??:?
 at ??:?
 at ??:?
 at ??:?
 at ??:?
 at ??:?
[11] #1  Foam::sigFpe::sigHandler(int)[23] #1  Foam::sigFpe::sigHandler(int) at ??:?
 at ??:?
 at ??:?
 at ??:?

...
[amd32n1:17226] *** Process received signal ***
[amd32n1:17226] Signal: Floating point exception (8)
[amd32n1:17226] Signal code:  (-6)
[amd32n1:17226] Failing at address: 0x2650000434a
[amd32n1:17226] [ 0] /lib64/libc.so.6[0x313b032510]
[amd32n1:17226] [ 1] /lib64/libc.so.6(gsignal+0x35)[0x313b032495]
[amd32n1:17226] [ 2] /lib64/libc.so.6[0x313b032510]
[amd32n1:17226] [ 3] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libincompressibleTurbulenceModels.so(_ZN4Foam3sqrIdNS_12fvPatchFieldENS_7volMeshEEEvRNS_14GeometricFieldINS_12outerProductIT_S5_E4typeET0_T1_EERKNS3_IS5_S8_S9_EE+0x72)[0x7fb6cfa604c2]
[amd32n1:17226] [ 4] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libincompressibleTurbulenceModels.so(_ZN4Foam3sqrIdNS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_12outerProductIT_S6_E4typeET0_T1_EEEERKNS4_IS6_S9_SA_EE+0x136)[0x7fb6cfacfd56]
[amd32n1:17226] [ 5] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libfieldFunctionObjects.so(_ZNK4Foam15functionObjects12fieldAverage28calculatePrime2MeanFieldTypeINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES6_EEvl+0x10e)[0x7fb6a5bf679e]
[amd32n1:17226] [ 6] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects12fieldAverage12calcAveragesEv+0x225)[0x7fb6a5ba1ef5]
[amd32n1:17226] [ 7] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects12fieldAverage7executeEv+0xa)[0x7fb6a5b946ba]
[amd32n1:17226] [ 8] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x2e)[0x7fb6cbe8b01e]
[amd32n1:17226] [ 9] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x46)[0x7fb6cbe81246]
[amd32n1:17226] [10] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0x91)[0x7fb6cbe8ea51]
[amd32n1:17226] [11] pimpleFoam[0x4246ae]
[amd32n1:17226] [12] /lib64/libc.so.6(__libc_start_main+0xfd)[0x313b01ed1d]
[amd32n1:17226] [13] pimpleFoam[0x4265ed]
[amd32n1:17226] *** End of error message ***
 at ??:?
[amd32n1:17219] *** Process received signal ***
[amd32n1:17219] Signal: Floating point exception (8)
[amd32n1:17219] Signal code:  (-6)
[amd32n1:17219] Failing at address: 0x26500004343
[amd32n1:17219] [ 0] /lib64/libc.so.6[0x313b032510]
[amd32n1:17219] [ 1] /lib64/libc.so.6(gsignal+0x35)[0x313b032495]
[amd32n1:17219] [ 2] /lib64/libc.so.6[0x313b032510]
[amd32n1:17219] [ 3] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libincompressibleTurbulenceModels.so(_ZN4Foam3sqrIdNS_12fvPatchFieldENS_7volMeshEEEvRNS_14GeometricFieldINS_12outerProductIT_S5_E4typeET0_T1_EERKNS3_IS5_S8_S9_EE+0x72)[0x7f7625a314c2]
[amd32n1:17219] [ 4] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libincompressibleTurbulenceModels.so(_ZN4Foam3sqrIdNS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_12outerProductIT_S6_E4typeET0_T1_EEEERKNS4_IS6_S9_SA_EE+0x136)[0x7f7625aa0d56]
[amd32n1:17219] [ 5] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libfieldFunctionObjects.so(_ZNK4Foam15functionObjects12fieldAverage28calculatePrime2MeanFieldTypeINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES6_EEvl+0x10e)[0x7f75f61f479e]
[amd32n1:17219] [ 6] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects12fieldAverage12calcAveragesEv+0x225)[0x7f75f619fef5]
[amd32n1:17219] [ 7] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects12fieldAverage7executeEv+0xa)[0x7f75f61926ba]
[amd32n1:17219] [ 8] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x2e)[0x7f7621e5c01e]
[amd32n1:17219] [ 9] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x46)[0x7f7621e52246]
[amd32n1:17219] [10] /raid/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0x91)[0x7f7621e5fa51]
[amd32n1:17219] [11] pimpleFoam[0x4246ae]
[amd32n1:17219] [12] /lib64/libc.so.6(__libc_start_main+0xfd)[0x313b01ed1d]
[amd32n1:17219] [13] pimpleFoam[0x4265ed]
[amd32n1:17219] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 1 with PID 17209 on node amd32n1 exited on signal 8 (Floating point exception).
--------------------------------------------------------------------------

[mAlletto]

Ok seems like the simulation is not deverging immediately.

How good is the mesh quality? What is the checkMesh output?

Maybe underrelaxing a bit more in the beginning helps a bit.

Or maybe you can use in the beginning a bit more diffusive schemes.

Or maybe maybe you can write out a few iteration and check where the divergence starts (look for high values of U, p, k, omega a.s.o)

some tricks how to set the schemes:

http://www.wolfdynamics.com/wiki/OFtipsandtricks.pdf

[cyln]

My mesh quality is quite high as below. Convergence rate of this mesh for laminar simulation was very good.

I think using more diffusive (first order) schemes will not solve my problem because I already have a very good initial solution from fully unstructured grid. I map my data to this new hybrid mesh and restart the simulation.

I am writing a couple of time steps to find where the divergence starts, however, the first time step is already fully diverged (see residual figure). The divergence occurs once the turbulence parameters are solved (at the last outer loop iteration, see residual figure).

I think there is a very big mistake I make associated with the interfaces as the simulation diverges right at the beginning. It makes me so sad that I cannot see it.

By the way, my fvSchemes are already set according the document you linked.

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 4.1
Exec   : checkMesh
Date   : Sep 17 2018
Time   : 20:47:29
Host   : "amd64n1"
PID    : 22616
Case   : /files1/home/ucaylan/BBody17
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

Overriding DebugSwitches according to controlDict
    SolverPerformance 2;

    lduMatrix       2;

    GAMG            1;

    GAMGAgglomeration 1;

Create polyMesh for time = 0.382125

Time = 0.382125

Mesh stats
    points:           18274985
    faces:            68854026
    internal faces:   67971616
    cells:            25805557
    faces per cell:   5.30218
    boundary patches: 7
    point zones:      0
    face zones:       2
    cell zones:       2

Overall number of cells of each type:
    hexahedra:     14739725
    prisms:        4123964
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    6941868
    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: 2
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "0.382125/cellToRegion"
  <<Writing region 0 with 11065832 cells to cellSet region0
  <<Writing region 1 with 14739725 cells to cellSet region1

Checking patch topology for multiply connected surfaces...
    Patch               Faces    Points   Surface topology                  
    FARFIELD            65021    32626    ok (non-closed singly connected)  
    OUTLET              6249     3240     ok (non-closed singly connected)  
    BODY                158614   79309    ok (closed singly connected)      
    INTERFACET          249569   124939   ok (non-closed singly connected)  
    INTEROUTT           40559    20434    ok (non-closed singly connected)  
    INTERFACE           308799   309264   ok (non-closed singly connected)  
    INTEROUT            53599    54064    ok (non-closed singly connected)  

Checking geometry...
    Overall domain bounding box (-3.6 -1.89 -1.638) (5.4594 1.89 1.638)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-1.04794e-17 -1.96074e-16 1.02085e-16) OK.
    Max cell openness = 1.31454e-14 OK.
    Max aspect ratio = 212.706 OK.
    Minimum face area = 2.4302e-09. Maximum face area = 0.010222.  Face area magnitudes OK.
    Min volume = 5.30966e-13. Max volume = 0.000318869.  Total volume = 86.5233.  Cell volumes OK.
    Mesh non-orthogonality Max: 71.662 average: 8.20686
   *Number of severely non-orthogonal (> 70 degrees) faces: 2.
    Non-orthogonality check OK.
  <<Writing 2 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 2.6963 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

[mAlletto]

Maybe you can initialize nut with a value greater than zero.

[cyln]

When I map the data from last time step of the unstructured grid, nut field already has non-zero values :/ so I tried that too

[mAlletto]

Maybe during the mapping something went wrong. Did you try to start the simulation without mapping.

[cyln]

Yea, I tried both :/

It diverges whenever it solves the turbulent parameters k song omega. I can make OF solve k and omega every outer loop iteration or I can solve k and omega at the last outer loop iteration. At the current case, I am solving it at the last outer loop iteration and that's where the simulation diverges. If I solve k and omega every outer-loop oteration, the simulation diverges at the first outer loop iteration.

[mAlletto]

Maybe at the processor boundary the values oft omega are 0. otherwise I really don't know what could happen without seeing the solution.