[macbeth]

Hi,

I have read in some of the posts here that there could be a problem with the calculation of integral forces when using SRF (single reference frame) solvers.
It was said here somewhere that the torque e.g. on windmills is way too high.

Being quite new to OpenFOAM, I set up a case for a wind turbine and after some time got it working. I used the "forces"-function in the controldict and instantly ran into the same problem.

To bring some light into that case, I used paraview to compute the forces acting upon the surface of the blades.
(Quite tricky: extract block, generate normals, multiply p with normals, integrate values... et voila: Forces in X,Y,Z-directions.
For the torque we need to use the cross-product of (p*normals) and the coordinate-vector. Integration of that gives the moments.)

Now, if i compare this to the values I get from the forces-function, values are about 20% lower. Much more like I would expect them to be. So is the post-processing in OF damaged? Or maybe it doen't like simpleSRFFoam??

Does anybody else have similar experience?

Next question on my heart is the bc for a freestream around a wind turbine...

I tried to use a "slip" condition and was surprised that there seemed to be a boundary layer (at least looking at Uabs). can anybody suggest which bcs to use? Do I need something special for SRF? I have a cylindrical area around the blades, 2D upstream and 10D downstream.

Thx!
macbeth

[be_inspired]

Did you get some results with SRFFoam over windmills? I have problems with bcs. Continuity errors are increasing each iteration, but I do not know where the problem is.
I think the case is similar yours, but I use cyclic condition. I am studying a 120º sector.

[macbeth]

I wasn't able to "tame" SRFFoam. I kept getting strange results on the free stream BCs on the outside region.
So finally I went for MRFSimpleFoam with a rotating "rotor-region" that encloses the blades.
The setup is a bit more tricky, but now I have a small script that calls snappyHexMesh and all the "cellSet" and "faceSet"-stuff.
The results look ok. But I still have to find a validation case or some "hard" real world data.
How are you coming along with SRFFoam?

[be_inspired]

With SRFFoam, actually I am not able to reach a valid solution.
With MRFFoam I obtain convergence problems too, so I do not know were is the problem ( mesh or setup).

In your case, Are you studying a 120º sector or a 360º region?
Could you explain the cellset, faceset and those stuffs to setup a case?

I have been reading all along the forum, but in clear, I do not reach a valid solution.

[macbeth]

Hi be_insipred

I used a 360° region just to keep it simple .I'll try to explain my setup briefly:

Here is a quick summary:

1. blockMesh
2. snappyHexMesh
3. create zones and faces
4. run MRFSimpleFoam

Here are some details:

I have uploaded some pictures that show how I set up blockMesh.
Note that he inner region of my blockMesh is a cylinder. Later, when I define the "rotor-Cellset" I use the same dimensions (cellset-diameter = inner blockmesh-diameter)

After running snappyHexMesh, I have added a cellZone named "rotor" (red in the picture) with a simple cellSetDict:

system/cellSetDict

 
name 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 with centre within cylinder
    cylinderToCell
    {                         // blockmesh-Raster: 25m/40=.625
       p1       (-0.625 0 0); // start point on cylinder axis
       p2       (1.875 0 0);   // end point on cylinder axis
       radius   2.6;
    }

);

To "integrate" this rotor zone into the blockmesh, call

cellSet
setsToZones -noFlipMap

The next step is to create faces.
(Here I'm not sure if this step is needed any more with OpenFOAM 1.7.x. Maybe someone can comment on this?)

Anyway, I have done this:

1. create a faceSetDict in the system-directory:

./system/faceSetDict

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

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

 // One of clear/new/invert/add/delete|subset/list
 action new;
 topoSetSources
(
      cellToFace
     {
         set rotor;
         option all;   // Takes all the faces from the CellSet named rotor
     }
);

2. call faceSet:

faceSet

3. substitute the system/faceSetDict with this faceSetDict:

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


name rotor;                     // Name of the faceSet

 // One of clear/new/invert/add/delete|subset/list
 action delete;
 topoSetSources
 (
      boundaryToFace
     {
     }
);

4. call faceSet AGAIN, followed by setsToZones:

faceSet
setsToZones -noFlipMap

Now, if you have a definition for the MRF - zone in your constant-directory like this:

./constant/MRFZones

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

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

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

... you should be ready to run

MRFSimpleFoam

... I hope I didn't miss something ...

BTW: In the attached pictures I have skipped the "snappyHexMesh"-step to keep the pictures clearer

[be_inspired]

Thank you very much!! I appreciate a lot your help but sorry, I have some questions.

In the step 3, the FaceSetDict is the same as the commented at step 1. Is this correct? Do you say that it is necessary to substitute the file.

Then, MRF equations are only applied in rotor zone? Do you have any jump in flow field from inner zone to rotor zone? I do not understand why it is necessary to define a rotor zone if there is only 1 rotor and no stator.

Thanks a lot!!

[macbeth]

Hi,

I have edited my post to make the changes in the faceSetDicts clearer.
Yes, you have to call faceSet twice (with different faceSetDicts).
In the first run you have

action new

and in the second you delete the boundary face with

action delete

(sorry about my confusing post. Both of my faceSetDicts in this post looked very similar. The only difference were comment- and uncomment-symbols /* ... */ . I have edited the post, now the difference should be clear).

The reason I chose MRF was that I was not able to set the boundary conditions to something like freestream in SRF. The solution always showed some kind of boundary layer on the sides of the cylinder.
So I went for MRF with a big non-rotating zone and a small rotating zone.
There is no inconsistency in the flowfield between the zones.

Something I have not figured out so far:
In the post processing I'm not able to "switch" to relative flow. In SRF you get U_abs and U_rel. MRF only uses U.

Question to all: How can I calculate U_rel for a rotation MRF-zone?

@be_inspired: let me know if your case works!!

[jiaojiao]

Originally Posted by macbeth

Hi be_insipred

I used a 360° region just to keep it simple .I'll try to explain my setup briefly:

Here is a quick summary:

1. blockMesh
2. snappyHexMesh
3. create zones and faces
4. run MRFSimpleFoam

Here are some details:

I have uploaded some pictures that show how I set up blockMesh.
Note that he inner region of my blockMesh is a cylinder. Later, when I define the "rotor-Cellset" I use the same dimensions (cellset-diameter = inner blockmesh-diameter)

After running snappyHexMesh, I have added a cellZone named "rotor" (red in the picture) with a simple cellSetDict:

system/cellSetDict

 
name 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 with centre within cylinder
    cylinderToCell
    {                         // blockmesh-Raster: 25m/40=.625
       p1       (-0.625 0 0); // start point on cylinder axis
       p2       (1.875 0 0);   // end point on cylinder axis
       radius   2.6;
    }

);

To "integrate" this rotor zone into the blockmesh, call

cellSet
setsToZones -noFlipMap

The next step is to create faces.
(Here I'm not sure if this step is needed any more with OpenFOAM 1.7.x. Maybe someone can comment on this?)

Anyway, I have done this:

1. create a faceSetDict in the system-directory:

./system/faceSetDict

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

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

 // One of clear/new/invert/add/delete|subset/list
 action new;
 topoSetSources
(
      cellToFace
     {
         set rotor;
         option all;   // Takes all the faces from the CellSet named rotor
     }
);

2. call faceSet:

faceSet

3. substitute the system/faceSetDict with this faceSetDict:

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


name rotor;                     // Name of the faceSet

 // One of clear/new/invert/add/delete|subset/list
 action delete;
 topoSetSources
 (
      boundaryToFace
     {
     }
);

4. call faceSet AGAIN, followed by setsToZones:

faceSet
setsToZones -noFlipMap

Now, if you have a definition for the MRF - zone in your constant-directory like this:

./constant/MRFZones

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

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

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

... you should be ready to run

MRFSimpleFoam

... I hope I didn't miss something ...

BTW: In the attached pictures I have skipped the "snappyHexMesh"-step to keep the pictures clearer

your mesh looks similar with mine,I have some problems to consult you. What tool do you use to generae the mesh? When you make the mesh,whether define the interfaces of the diffierent zones? If not,does the interface made by dict such as the toposet or fvoption file？ why do you delete the face by steps 3? Please help me with the confusion. Thank you.