[windmachines]

Hi All,

I am trying to simulate a wind turbine blade inside a 60 degree periodic wedge with cyclicAMI boundaries. The problem is that, even though I am including those boundaries in "nonRotatingPatches" in fvOptions, the MRF zone influences the pressure and velocity of the fluid at the boundaries.

Does anyone have a clue why this is happening? I have looked at similar posts on the forum without any progress, and being able to run snappyHexMesh in parallel would save a lot of time.

Thanks for taking the time to read this!

Ash

case:
https://www.dropbox.com/s/8muroalthy...iamond_ami.zip

images:
https://www.dropbox.com/s/y2x7t9tg9k...2014_07_25.png
https://www.dropbox.com/s/odqt3nes3k...2014_08_18.png
https://www.dropbox.com/s/b0v4e0ms1c...2014_09_53.png

[windmachines]

Does anyone have any insight?

The mrf zone behaves like a rotating solid only on the ami boundaries. Everything works perfectly with regular cyclic boundaries. There doesnt seem to be any problems with the mesh. Let me know if i should give any more info.

Thanks for your attention

Ash

[wyldckat]

Greetings Ash,

I've had this thread of yours on my to-do list for some time now and I finally managed today to have a look into this.

From what I can figure out, you have this in your "system/fvOptions" file:

MRF1
{
    type            MRFSource;
    active          yes;
    selectionMode   cellZone;
    cellZone        MRFZone;
    nonRotatingPatches (cyc0 cyc1);

    MRFSourceCoeffs
    {
        origin      (0 0 0);
        axis        (1 0 0);
        omega       -0.056744;//10mph wind, tsr=2.09
    }
}

I went looking into the source code and at the tutorials in OpenFOAM 2.2.2 (which seems to be the version you're using) and I used the following command to find tutorials that used this feature:

find $FOAM_TUTORIALS -name fvOptions | xargs grep -sl nonRotatingPatches

One of them has this:

MRF1
{
    type            MRFSource;
    active          yes;
    selectionMode   cellZone;
    cellZone        rotor;

    MRFSourceCoeffs
    {
        // Fixed patches (by default they 'move' with the MRF zone)
        nonRotatingPatches ();

        origin    (0 0 0);
        axis      (0 0 1);
        omega     constant 1047.2;
    }
}

Notice on which side "nonRotatingPatches" is located?
If you haven't spotted it yet, unfortunately you placed the entry in the wrong block of settings. It's meant to be inside the "MRFSourceCoeffs" block.

Best regards,
Bruno

[overdrive]

Hello!
I observed a similiar problem and none of the threads here could help me. I simulate the flow around a blade within a cylindrical 120°-domain using MRFSimpleFoam and cyclicAMI bc's with OpenFOAM 2.1. Then, I had a look at the velocity-distribution "U" in paraFoam and noticed that the direction of U at the cyclicAMI boundaries does not make any sense: The U_y-values are obviously in opposing directions (but the U-magnitude-values seem to be correct!!). Please have a look at the pictures (only the periodic faces are visible):

https://www.dropbox.com/s/sm2ipqgnij...U_mag.png?dl=0

https://www.dropbox.com/s/694sboys6cesjjl/U_y.png?dl=0

The same problem occurs by using "cyclic"-bcs. Some information regarding the setup:

• mesh generation with ICEM-CFD (with rotational periodicity, periodic faces, periodic BCs)
• cyclic patches in MRFZones declared as nonRotatingPatches
• cyclic patches in decomposePar declared in preservePatches
• mass balance fullfilled

Does someone have a clue what might be the problem? Do I have to invert the faces somehow e.g. in topoSetDict-file?? Or is it just an "error in my logic"?


Kind Regards,
Stefan

[wyldckat]

Quick answer:

1. The images did not get successfully attached
   Please edit the post and attach the images.
2. Please share at least the configuration files, such as the ones in "constant" and in "system".

[overdrive]

Thanks for your quick answer, Bruno! Sry about the pictures/missing files:


constant/MRFZones

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      MRFZones;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

1
(
    RotatingZone
    {
        //patches();// Fixed patches (by default they 'move' with the MRF zone)
        nonRotatingPatches (INLET OUTLET SHROUD HUB PERI1 periodic_sh); 

        origin    (0 0 0);
        axis      (0 0 1);
        omega     constant -1.7647;
    }
)

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

system/controlDict

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

application        MRFSimpleFoam;

startFrom       startTime;

startTime       0;

stopAt          endTime;//endTime; //writeNow

endTime         5000;

deltaT          1;

writeControl    timeStep;

writeInterval   150;

purgeWrite      2;

writeFormat     ascii;

writePrecision  6;

writeCompression off;

timeFormat      general;

timePrecision   6;

runTimeModifiable true;

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

system/topoSetDict:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      topoSetDict;
}

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


actions
(
  {
    name    RotatingSet;
    type    cellSet;
    action  new; /
    source  boxToCell; 
    sourceInfo
    {
      box (-100000 -100000 -100000) (1000000 1000000 100000);
    }
  }
  
  {
    name    RotatingZone; 
    type    cellZoneSet;
    action  new; 
    source  setToCellZone; 
    sourceInfo
    {
      set RotatingSet;
    }
  }
  
  
);


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

0/U

FoamFile
{
    version     2.0;
    format      ascii;
    class       volVectorField;
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

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

internalField   uniform (0 0 0);

boundaryField
{
    
    INLET
    {
        type            fixedValue;
        value           uniform (0 0 3.0);
    }

    OUTLET
    {
        type            zeroGradient;
    }

    SHROUD
    {
        type            slip;
    }

    HUB
    {
        type            slip;
    }

    PERI1
    {
           type          cyclicAMI;
    }

    periodic_sh
    {
        type          cyclicAMI;
    }


    BLADE
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
  
}

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

 FoamFile
{
    version     2.0;
    format      ascii;
    class       polyBoundaryMesh;
    location    "constant/polyMesh";
    object      boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

7
(
    INLET
    {
        type            patch;
        nFaces          13321;
        startFace       5170598;
    }
    OUTLET
    {
        type            patch;
        nFaces          13321;
        startFace       5183919;
    }
    PERI1
    {
        type            cyclicAMI;
        nFaces          18684;
        startFace       5197240;
        matchTolerance  0.0001;
        neighbourPatch  periodic_sh;
        transform       rotational;
        rotationAxis    (0 0 1);
        rotationCentre  (0 0 0);
    }
    periodic_sh
    {
        type            cyclicAMI;
        nFaces          18684;
        startFace       5215924;
    matchTolerance  0.0001;
        neighbourPatch  PERI1;
        transform       rotational;
        rotationAxis    (0 0 1);
        rotationCentre  (0 0 0);
    }
    SHROUD
    {
        type            wall;
        nFaces          10864;
        startFace       5234608;
    }
    HUB
    {
        type            wall;
        nFaces          9690;
        startFace       5245472;
    }
    BLADE
    {
        type            wall;
        nFaces          12836;
        startFace       5255162;
    }
)

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

[wyldckat]

Hi Stefan,

I finally managed to give a look into this. I suspect that it might be due to the exact minor version of OpenFOAM 2.1 you're using. In other words, you might be using a version that has a bug that has already been fixed in newer versions.

Do you know which exact version you're using of OpenFOAM? Is it one of these?

• 2.1.0
• 2.1.1
• 2.1.x

Best regards,
Bruno

[overdrive]

OpenFoam 2.1x12.3 (2.1-c1330db6b6e8) for Linux Suse 12.3

Actually, I am not sure if it is really a bug now. I computed the U_x and U_y values in a certain cell of PERI1 and in the corresponding one of periodic_sh. Then, I computed the normal component of these vectors and found out that the U-direction seem to be okay. But I am not really sure about this explanation attempt....

Kind regards,
Stefan

[wyldckat]

Hi Stefan,

Indeed, that commit refers to one of the few last commits in 2.1.x.

Unfortunately these past months I haven't had enough free time to set-up example cases to check situations like these myself. The initial images you provided do give a strange notion that something wrong is going on.

If you could provide/share a simple example case that reproduces this problem, I or anyone else could give it a try with more than one version of OpenFOAM and try to diagnose what's going on, namely if it's something that's already been fixed or not.

Best regards,
Bruno

[overdrive]

Hi Bruno,
thanks for your advice. Before doing example-test-cases, let me ask one another question regarding the topoSetDict-file (maybe the reason of the problem is in here). I only defined a cellZone (cellZoneSet). Does MRFSimpleFoam need a faceZone (faceZoneSet) with the same name, too? Or is not necessary?
Kind regards,
Stefan

[wyldckat]

Hi Stefan,

Originally Posted by overdrive

I only defined a cellZone (cellZoneSet). Does MRFSimpleFoam need a faceZone (faceZoneSet) with the same name, too? Or is not necessary?

As far as I can remember, only the cellZone is used for the MRF calculations. And from what I can see in the source code, faceZones are not even mentioned.

What is important is that the patches that are meant to be not moving should be identified accordingly. Unless there is one or more patches that you listed and that aren't part of (or within) the aforementioned cellZone.

The other thing that comes to mind is that the mesh might be unsuitable for simulating with OpenFOAM, at least not without taking a few more counter-measures. Which reminds me that I forgot to ask about the mesh stats, namely the output from this command:

checkMesh -allTopology -allGeometry

Best regards,
Bruno

[overdrive]

Hi Bruno,

I appreciate your help, thanks! I checked the MRF-Code, too, and yes, you're right (maybe faceZones might be needed in older versions).

The MRF-cellZone includes the whole domain, it's the only cellZone in my case. All patches (mentioned in the boundary-file above) except of "BLADE" are non-rotating patches and are defined in constant/MRFZones. Is there another way to declare them?

checkMesh-results:

Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           2864496
    faces:            8449612
    internal faces:   8306618
    cells:            2792705
    boundary patches: 7
    point zones:      0
    face zones:       1
    cell zones:       1

Overall number of cells of each type:                                                                                                                                                        
    hexahedra:     2792705                                                                                                                                                                   
    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.
    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
    INLET               21164    21456    ok (non-closed singly connected)   (0.908437 -27.9726 -32.3) (32.2998 27.9726 -32.3)
    OUTLET              21164    21456    ok (non-closed singly connected)   (0.908437 -27.9726 32.3) (32.2998 27.9726 32.3)
    SHROUD              21697    21952    ok (non-closed singly connected)   (16.15 -27.9726 -32.3) (32.2999 27.9726 32.3)
    HUB                 17858    18224    ok (non-closed singly connected)   (0.908437 -1.57346 -32.3) (1.81687 1.57346 32.3)
    BLADE               28255    28368    ok (non-closed singly connected)   (1.61829 -0.874904 -0.293274) (8.075 0.874904 0.293278)
    side1               16428    16688    ok (non-closed singly connected)   (0.908437 -27.9726 -32.3) (16.15 -1.57346 32.3)
    side2               16428    16688    ok (non-closed singly connected)   (0.908437 1.57346 -32.3) (16.15 27.9726 32.3)

Checking geometry...
    Overall domain bounding box (0.908437 -27.9726 -32.3) (32.2999 27.9726 32.3)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (2.96852e-15 -9.66145e-17 -2.90233e-16) OK.
    Max cell openness = 2.67082e-15 OK.
    Max aspect ratio = 178.188 OK.
    Minimum face area = 1.83031e-08. Maximum face area = 13.1418.  Face area magnitudes OK.
    Min volume = 1.69422e-11. Max volume = 8.9323.  Total volume = 70323.5.  Cell volumes OK.
    Mesh non-orthogonality Max: 59.195 average: 18.523
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 1.76821 OK.
    Coupled point location match (average 1.06121e-09) OK.
    Face tets OK.
    Min/max edge length = 0.000122124 4.616 OK.
    All angles in faces OK.
    Face flatness (1 = flat, 0 = butterfly) : average = 0.999993  min = 0.998877
    All face flatness OK.
    Cell determinant (wellposedness) : minimum: 1.64797e-05 average: 0.827782
 ***Cells with small determinant found, number of cells: 21065
  <<Writing 21065 under-determined cells to set underdeterminedCells
    Concave cell check OK.

Failed 1 mesh checks.

End

You can see the under-determined cells here:
https://www.dropbox.com/s/deuevzr2pg...mined.png?dl=0

I really bend over backwards with the mesh and I don't know how to avoid these elements without increasing the number of cells. Moreover, none of these elements are periodic ones. Do you think that these elements could cause problems?

Kind regards,
Stefan

[wyldckat]

Hi Stefan,

Those under-determined cells don't seem to be the ones responsible for the results you're seeing.

I have the vague feeling of this being familiar to some bug report I saw on the bug tracker... perhaps I'm confusing with your first images I saw here on this thread.
Honestly, a simplified test case is the way to go. The least number of parts/patches, the better. This way it'll be easier to assess what is the problem.

Best regards,
Bruno

[sharonyue]

Hello！

for my simulaions, I use AMI to deal with sliding mesh with an solver which can deal with dynamic mesh. Or, I use AMI to deal with two different mesh zones cases in which the face mesh nodes on the interface of these zones are not matched.

I notice u are using MRFSimpleFoam, it can not handle dynamic mesh, so does that mean your mesh nodes are not matched? otherwise why dont u just delete the AMI patches to see the result?

best,

[neiht]

When using latest Openfaom version, simulation using MRF is quite simple. You just need a cell zone, and setting in system/fvOption.
However in the old version like oF211, we need create cyclicAMI boundaries. In my simulation for windturbine, i used DOFI ( a new interface for OpenFoam). So easy! you can find detail in the case created to see how it create AMI

[overdrive]

I notice u are using MRFSimpleFoam, it can not handle dynamic mesh

I don't need an interface between the rotating and non-rotating zone. I think this job is done by the MRF-solver itself, right?!? I just needed the cyclicAMI-patches for my periodic faces, because I just meshed one of three blades within a 120°-domain. Actually, the nodes should match, but OpenFOAM complains about them. That's why I decided to generate these periodic patches again in OpenFOAM with the createPatch-tool. Now, I run my simulation with BC type "cyclic", I don't need cyclicAMI patches anymore......

you can find detail in the case created to see how it create AMI

Can you give me some more information about your case?

Kind regards,
Stefan

[miladrakhsha]

Originally Posted by wyldckat

Hi Stefan,


As far as I can remember, only the cellZone is used for the MRF calculations. And from what I can see in the source code, faceZones are not even mentioned.

What is important is that the patches that are meant to be not moving should be identified accordingly. Unless there is one or more patches that you listed and that aren't part of (or within) the aforementioned cellZone.

The other thing that comes to mind is that the mesh might be unsuitable for simulating with OpenFOAM, at least not without taking a few more counter-measures. Which reminds me that I forgot to ask about the mesh stats, namely the output from this command:

checkMesh -allTopology -allGeometry

Best regards,
Bruno

Hi Bruno,

I know it has been a while since you responded to this question, but I was wondering if you could help me with my question too.
I am using OpenFoam 3.0, and I have a similar problem. In my case I have AMI patches inside the moving domain as shown in the pictures.

So basically I have 3 AMI patches (x2) for the 3 radial faces that connect the three 120^o domains together. I also have another one that connect the structured mesh around the airfoils to the unstructured grid. Finally I have another circular AMI patch that separates the moving cells from the stationary ones.

I need the inner AMI patches since the meshes of different domain are not conforming at the interface.

So what I have tried is to add only the circular patch to the nonRotatingPatches(); in the constant/MRFProperties
However, the solver crashes after a few time steps.
I tried to add all the AMI patches to the nonRotatingPatches() , and realized that the solver works Okay, but when I visualize the data I do not see any rotational effects in the flow field as if everything inside the domain is fixed.
I am a little bit confused about the terminology here: Does fixed patches means they are fixed in GRF ? or they are the interfaces patches that are not moving with the moving domain?
// Fixed patches (by default they 'move' with the MRF zone)????

I believe the mesh quality is good enough as this case ran Okay with pimpleDyMFoam, but now that I am trying MRFSimpleFoam (simpleFoam+ constant/MRFPropeties) it crashes.

Screenshot 2016-09-12 20.27.41.png
Screenshot 2016-09-12 20.29.21.png