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

problem with cyclicAMI periodic boundaries inside MRF zone

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 2 Post By wyldckat

Reply
 
LinkBack Thread Tools Display Modes
Old   August 14, 2014, 13:42
Default problem with cyclicAMI periodic boundaries inside MRF zone
  #1
New Member
 
Ash Sechler
Join Date: Feb 2014
Posts: 5
Rep Power: 3
windmachines is on a distinguished road
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 is offline   Reply With Quote

Old   August 24, 2014, 12:51
Default
  #2
New Member
 
Ash Sechler
Join Date: Feb 2014
Posts: 5
Rep Power: 3
windmachines is on a distinguished road
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
windmachines is offline   Reply With Quote

Old   September 28, 2014, 15:44
Default
  #3
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,516
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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:
Code:
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:
Code:
find $FOAM_TUTORIALS -name fvOptions | xargs grep -sl nonRotatingPatches
One of them has this:
Code:
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
ashim and Bluewater like this.
wyldckat is offline   Reply With Quote

Old   November 9, 2014, 11:08
Default
  #4
New Member
 
Join Date: Nov 2013
Posts: 10
Rep Power: 3
overdrive is on a distinguished road
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

Last edited by overdrive; November 11, 2014 at 06:04.
overdrive is offline   Reply With Quote

Old   November 9, 2014, 11:39
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,516
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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".
wyldckat is offline   Reply With Quote

Old   November 10, 2014, 04:49
Default
  #6
New Member
 
Join Date: Nov 2013
Posts: 10
Rep Power: 3
overdrive is on a distinguished road
Thanks for your quick answer, Bruno! Sry about the pictures/missing files:


constant/MRFZones
Code:
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
Code:
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:
Code:
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

Code:
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);
    }
  
}

// ************************************************************************* //
Code:
 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;
    }
)

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

Last edited by wyldckat; November 17, 2014 at 16:24. Reason: Added [CODE][/CODE]
overdrive is offline   Reply With Quote

Old   November 17, 2014, 16:34
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,516
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   November 18, 2014, 06:53
Default
  #8
New Member
 
Join Date: Nov 2013
Posts: 10
Rep Power: 3
overdrive is on a distinguished road
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
overdrive is offline   Reply With Quote

Old   November 23, 2014, 16:39
Default
  #9
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,516
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   December 10, 2014, 11:11
Default
  #10
New Member
 
Join Date: Nov 2013
Posts: 10
Rep Power: 3
overdrive is on a distinguished road
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
overdrive is offline   Reply With Quote

Old   December 13, 2014, 20:45
Default
  #11
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,516
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Stefan,

Quote:
Originally Posted by overdrive View Post
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:
Code:
checkMesh -allTopology -allGeometry
Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   December 15, 2014, 10:33
Default
  #12
New Member
 
Join Date: Nov 2013
Posts: 10
Rep Power: 3
overdrive is on a distinguished road
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:

Code:
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
overdrive is offline   Reply With Quote

Old   December 15, 2014, 15:46
Default
  #13
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,516
Blog Entries: 34
Rep Power: 86
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   December 21, 2014, 19:27
Default
  #14
Senior Member
 
Dongyue Li
Join Date: Jun 2012
Location: Torino, Italy
Posts: 676
Rep Power: 8
sharonyue is on a distinguished road
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,
sharonyue is offline   Reply With Quote

Old   January 22, 2015, 02:19
Default mrf ZONE
  #15
New Member
 
QuocThien
Join Date: Apr 2013
Posts: 9
Rep Power: 4
neiht is on a distinguished road
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
neiht is offline   Reply With Quote

Old   January 22, 2015, 06:26
Default
  #16
New Member
 
Join Date: Nov 2013
Posts: 10
Rep Power: 3
overdrive is on a distinguished road
Quote:
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......

Quote:
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
overdrive is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Error in solution using "Grid Interface" agustinvo FLUENT 4 January 20, 2015 13:03
[GAMBIT] periodic faces not matching Aadhavan ANSYS Meshing & Geometry 6 August 31, 2013 11:25
Problem in running ICEM grid in Openfoam Tarak OpenFOAM 6 September 9, 2011 17:51
2D periodic problem Markus CFX 0 August 4, 2008 14:43
Fluent incident radiation problem Michael Schwarz Main CFD Forum 0 October 21, 1999 05:56


All times are GMT -4. The time now is 19:55.