[Ivanet]

Hi folks,
I have the following problem with MRFSimpleFoam: I am trying to simulate a small wind turbine. In my cellSetDict I select the cells where the Coriolis forces are applied. I do that with boxToCell and I call that region rotor:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  1.5                                   |
|   \\  /    A nd           | Web:      http://www.OpenFOAM.org               |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      cellSetDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// Name of set to operate on
name rotor; //rotor;

// One of clear/new/invert/add/delete|subset/list
action new;

// Actions to apply to cellSet. These are all the topoSetSource's ending
// in ..ToCell (see the meshTools library).

topoSetSources
(
    // Cells in cell zone
    boxToCell
    {
    box (-2.5 -2.5 -1)(2.5 2.5 1);
    name rotor;      // name of cellZone

    }

);

Then I run cellSet in my makeMesh Script and convert the set to a zone:

cellSet
setsToZones -noFlipMap

cp system/faceSetDict_rotorFaces system/faceSetDict
faceSet

cp system/faceSetDict_noBoundaryFaces system/faceSetDict
faceSet

setsToZones -noFlipMap

In MRFZones I define the my geometry (Rotor_CATIASTL) as the rotating patch within the rotor region:

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

1
(
    rotor
    {
        patches (Rotor_CATIASTL);
        // Fixed patches (by default they 'move' with the MRF zone)
    //    nonRotatingPatches (); //(INFLOW,OUTFLOW,TOP);

        origin    origin [0 1 0 0 0 0 0]  (0 0 0);
        axis      axis   [0 0 0 0 0 0 0]  (0 0 1);
        omega     omega  [0 0 -1 0 0 0 0]  -44.4; 
    }
)

So far everything is OK. Now, I run the simulation and in the results I see strange flow effects in the boundary between the rotating and the non-rotating zone. In the pictures attached you can see what I mean. The rotating zone is the box you see in the pictures.

I have also tried to use a cylinder (as well as a sphere) for selecting the rotating cells, but I always get this problem at the "rotating- non-rotating" boundary region.
Do you have a clue why this happen and how it can be solved?
Thanks a lot in advance
Ivan

[madad2005]

From your images, it looks as though your main issue is that your farfield boundaries are too close to your region of interest. The upstream boundary should be at least 5 blade spans away, the downstream boundary should be at least 10 blade spans away, likewise your side boundaries. This is to prevent the boundary conditions having too strong an influence on the computed flow around the rotor.

Second thing. It is normally standard when modelling rotors with MRF's to have the entire domain as an MRF, with the domain boundaries normally forming a cylinder. I'm assuming you've placed the MRF within a non-rotating domain to simulate varying inflow ala ABL? This normally works best if a mixing plane is present between the rotating and non-rotating zones, but I don't believe that capability exists in OpenFOAM. Someone in the know could possibly elaborate on this further.

Anyway, I'd try both suggestions and see how things go. I'd be interested in seeing your results regardless.

[Ivanet]

Hi madad2005,
Thanks a lot for your quick reply. I have repeated the simulations with a larger domain, just as you propose. Unfortunately the results are still bad.
Actually I also wanted to consider my whole domain is rotating. However, if I do that, then the results are even more strange. That is why I was considering only a small zone as rotating region.
Now the goods news: Today I have managed to get reasonable results. Since I changed a couple of things at once in my simulation, I am still not sure which of my modifications was responsible for the better results. I will check that in the coming days and then I will post it.
Greetings
Ivan

[Ivanet]

Hi again, now I know where was the problem. As you can see in my first post, the MRFZones file contained a description of the rotating patches, but no definition of the non-rotating patches. That is wrong. Actually the rotating patches do not need to be defined here, since it will be assumed that all the cells defined within the cellSetDict are rotating cells. It is however important to define which patches do not rotate (inlet, outlet and outer walls).
Cheers
Ivan

[trantoan2008]

Originally Posted by Ivanet

Hi again, now I know where was the problem. As you can see in my first post, the MRFZones file contained a description of the rotating patches, but no definition of the non-rotating patches. That is wrong. Actually the rotating patches do not need to be defined here, since it will be assumed that all the cells defined within the cellSetDict are rotating cells. It is however important to define which patches do not rotate (inlet, outlet and outer walls).
Cheers
Ivan

HI Ivan

Can I ask you some question?
1. In your analysis, is there sliding mesh (OGI) technique that you used?
2. If i want to change rotation axis which will be changed with time dependent, it is possible?

I really appreciate your help. Thank you so much.

Tran

[Ivanet]

Hi Tran,
no, in my analysis I did not use any kind of sliding interface.
If you want to use MRFSimpleFoam you only need to define which regions of your domain rotate and which regions do not rotate. Here is explained in detail how to do it:
http://openfoamwiki.net/index.php/Si...vaned_diffuser

MRFSimpleFoam is a steady state solver. If you need a time dependant simulation, you should use a transient solver like e.g. pimpleDyMFoam. In that case you might use a GGI (general grid interface) in order to account for the rotation.
If you want to change the axis of rotation during the simulation I think you need to stop the simulation, modify the axis of rotation in your model and them restart the simulation again.
Greetings
Ivan

[neiht]

Can u explain more clearly? I have the same problem and I dont know how to solve

[Nolwenn]

Hi Ivan,

Did you solve your problem ? I have the same kind of problem, even if I specify inlet, outlet and side patches as fixed ...

Nolwenn

[be_inspired]

Similar problem here.

Any information about how to fix the problem?
In OF2.3.x (after fvOptions was included) it is not needed to perform any faceSet operation. Only cellSet is needed I think

After MRFZone, the swirl of the flow is lost and wake rotation is lost?