simpleSRFFoam and forces

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

 July 2, 2010, 12:44 simpleSRFFoam and forces #1 New Member   Join Date: Mar 2010 Posts: 7 Rep Power: 8 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

 October 29, 2010, 18:42 #2 Senior Member   M. Montero Join Date: Mar 2009 Location: Madrid Posts: 121 Rep Power: 9 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.

 November 2, 2010, 06:46 #3 New Member   Join Date: Mar 2010 Posts: 7 Rep Power: 8 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?

 November 2, 2010, 10:02 #4 Senior Member   M. Montero Join Date: Mar 2009 Location: Madrid Posts: 121 Rep Power: 9 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.

November 8, 2010, 13:07
#5
New Member

Join Date: Mar 2010
Posts: 7
Rep Power: 8
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
Code:
```
name rotor;

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
}

);```
To "integrate" this rotor zone into the blockmesh, call

Code:
```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
Code:
```FoamFile
{
version     2.0;
format      ascii;
class       dictionary;
object      faceSetDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

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

action new;
topoSetSources
(
cellToFace
{
set rotor;
option all;   // Takes all the faces from the CellSet named rotor
}
);```
2. call faceSet:

Code:
`faceSet`
3. substitute the system/faceSetDict with this faceSetDict:

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

name rotor;                     // Name of the faceSet

action delete;
topoSetSources
(
boundaryToFace
{
}
);```
4. call faceSet AGAIN, followed by setsToZones:

Code:
```faceSet
setsToZones -noFlipMap```
Now, if you have a definition for the MRF - zone in your constant-directory like this:

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

Code:
`MRFSimpleFoam`
... I hope I didn't miss something ...

BTW: In the attached pictures I have skipped the "snappyHexMesh"-step to keep the pictures clearer
Attached Images
 wt_blockmesh.jpg (75.0 KB, 58 views) wt_blockmesh_blade.jpg (49.4 KB, 65 views) wt_blockmesh_rotor.jpg (57.7 KB, 66 views) wt_blockmesh_blade1_side.jpg (53.3 KB, 62 views)

Last edited by macbeth; November 9, 2010 at 02:58.

 November 8, 2010, 14:59 #6 Senior Member   M. Montero Join Date: Mar 2009 Location: Madrid Posts: 121 Rep Power: 9 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!!

 November 9, 2010, 03:14 #7 New Member   Join Date: Mar 2010 Posts: 7 Rep Power: 8 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 Code: `action new` and in the second you delete the boundary face with Code: `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!!

February 20, 2014, 04:17
#8
Member

Fengjiao Bian
Join Date: Nov 2013
Location: beijing
Posts: 30
Rep Power: 5
Quote:
 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: blockMesh snappyHexMesh create zones and faces 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 Code: ``` 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 Code: ```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 Code: ```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: Code: `faceSet` 3. substitute the system/faceSetDict with this faceSetDict: Code: ```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: Code: ```faceSet setsToZones -noFlipMap``` Now, if you have a definition for the MRF - zone in your constant-directory like this: ./constant/MRFZones Code: ```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 Code: `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.

 Tags paraview, simplesrffoam

 Thread Tools Display Modes Linear Mode

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

All times are GMT -4. The time now is 13:04.