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

simpleSRFFoam and forces

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

Reply
 
LinkBack Thread Tools Display Modes
Old   July 2, 2010, 12:44
Default simpleSRFFoam and forces
  #1
New Member
 
Join Date: Mar 2010
Posts: 7
Rep Power: 8
macbeth is on a distinguished road
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
macbeth is offline   Reply With Quote

Old   October 29, 2010, 18:42
Default
  #2
Senior Member
 
M. Montero
Join Date: Mar 2009
Location: Madrid
Posts: 121
Rep Power: 9
be_inspired is on a distinguished road
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.
be_inspired is offline   Reply With Quote

Old   November 2, 2010, 06:46
Default
  #3
New Member
 
Join Date: Mar 2010
Posts: 7
Rep Power: 8
macbeth is on a distinguished road
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?
macbeth is offline   Reply With Quote

Old   November 2, 2010, 10:02
Default
  #4
Senior Member
 
M. Montero
Join Date: Mar 2009
Location: Madrid
Posts: 121
Rep Power: 9
be_inspired is on a distinguished road
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.
be_inspired is offline   Reply With Quote

Old   November 8, 2010, 13:07
Smile
  #5
New Member
 
Join Date: Mar 2010
Posts: 7
Rep Power: 8
macbeth is on a distinguished road
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;

// 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
Attached Images
File Type: jpg wt_blockmesh.jpg (75.0 KB, 58 views)
File Type: jpg wt_blockmesh_blade.jpg (49.4 KB, 65 views)
File Type: jpg wt_blockmesh_rotor.jpg (57.7 KB, 66 views)
File Type: jpg wt_blockmesh_blade1_side.jpg (53.3 KB, 62 views)

Last edited by macbeth; November 9, 2010 at 02:58.
macbeth is offline   Reply With Quote

Old   November 8, 2010, 14:59
Default
  #6
Senior Member
 
M. Montero
Join Date: Mar 2009
Location: Madrid
Posts: 121
Rep Power: 9
be_inspired is on a distinguished road
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!!
be_inspired is offline   Reply With Quote

Old   November 9, 2010, 03:14
Default
  #7
New Member
 
Join Date: Mar 2010
Posts: 7
Rep Power: 8
macbeth is on a distinguished road
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!!
macbeth is offline   Reply With Quote

Old   February 20, 2014, 04:17
Default
  #8
Member
 
Fengjiao Bian
Join Date: Nov 2013
Location: beijing
Posts: 30
Rep Power: 5
jiaojiao is on a distinguished road
Quote:
Originally Posted by macbeth View Post
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;

// 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.
jiaojiao is offline   Reply With Quote

Reply

Tags
paraview, simplesrffoam

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



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