[be_inspired]

Hi all,

I am playing with the new rotorDisk source implemented into OF2.2.x and apart from some code modification because a minor bug when converting a vector field from Cartesian coordinates to Cylindrical coordinates ( bug reported and pending to analyze), I am trying to introduce the polar curves and blade geometry using file but I can not.

The code below works and the geometrical information and polars are correctly read but I do not know to modify rotorDisk dict to introduce the information required using external files.

        blade
        {
        data ((profile1 (8 11.96 3.357)) (profile1 (10 9.45 3.323))); 
        }

        profiles 
        {
		profile1
		{
		type lookup;
		data ((-90 1.378 -0.09) (-60 1.04 -0.73) (-20 0.1755 -0.68) (-15 0.127 -0.59) (-12 0.07 -0.52) (-10 0.04 -0.43) (-9 0.0316 -0.43) (-8 0.0114 -0.39) (-7 0.018 -0.38) (-6 0.015 -0.24) (-5 0.011 -0.11) (-4 0.009 0.009) (-3 0.007 0.12) (-2 0.005 0.31) (-1 0.005 0.43) (0 0.00717 0.56) (1 0.006 0.62) (2 0.007 0.7691) (3 0.0074 0.9581) (4 0.0079 1.05) (5 0.008 1.2) (6 0.0085 1.25) (7 0.0089 1.37) (8 0.022 1.43) (9 0.014 1.54) (10 0.020 1.55) (11 0.025 1.417) (12 0.039 1.325) (13 0.056 1.285));
		}	          
        }

My intention is to validate the NREL Phase VI blade using Fluent Virtual Blade Model and Openfoam rotorDiskSource but now I need to introduce all the polar curves in the easiest way.

Best Regards

Marcelino

[GDTech]

Hi,

I also noticed a problem with cylindrical coordinate transformation when I wanted to use a rotorDiskSource not aligned with coordinate system in a uniform freestream flow. The rotorForce field solution was not asymmetric as expected.

I added these lines add the end of Foam::fv::rotorDiskSource::constructGeometry() :

c = cos(psi);
s = sin(psi);
Rcyl_[i] = tensor(c, s, 0, -s, c, 0, 0, 0, 1);
invRcyl_[i] = Rcyl_[i].T();

and I made these modifications in function Foam::fv::rotorDiskSource::calculate :

// velocity in local cylindrical reference frame
//vector Uc = coordSys_.localVector(U[cellI]);
vector Uc = coordSys_.R().T() & U[cellI];
Uc = Rcyl_[i] & Uc;
.
.
.
//vector localForce = vector(0.0, -f*Cd, tipFactor*f*Cl);
vector localForce = vector( 0.0, -f*Cd*cos(alphaEff)-tipFactor*f*Cl*sin(alphaEff), tipFactor*f*Cl*cos(alphaEff)-f*Cd*sin(alphaEff));
.
.
.
// convert force to global cartesian co-ordinate system
//force[cellI] = coordSys_.globalVector(localForce);
localForce = invRcyl_[i] & localForce;
force[cellI] = coordSys_.R() & localForce;

The solution is now more physical (see attachement).

Best regards.

[antar]

Hi Laurent

In this vector :

vector localForce = vector( 0.0, -f*Cd*cos(alphaEff)-tipFactor*f*Cl*sin(alphaEff), tipFactor*f*Cl*cos(alphaEff)-f*Cd*sin(alphaEff));

you are using effective angle of attack, should this not be
just angle of attack calculated earlier as :

atan2(-Uc.z(), Uc.y());

Please comment

Thanks
Antar

[be_inspired]

Hi all,

Laurent, All
In OF2.3.0 and above it seems that the line should be:

vector Uc = coordSys_.R().R().T() & U[cellI];

.
The same for the last line you posted.

I have not check the code, but one question:
R tensor put in relation global to local or local to global?
Why is firstly the inverse tensor and not in the opposite side? :

vector Uc = coordSys_.R().R() & U[cellI];
force[cellI] = coordSys_.R().R().T() & localForce;

.

Antar, I think It should be:

scalar inflowAngle = atan2(Uc.z(), Uc.y());
scalar alphaEff = -alphaGeom + inflowAngle

and

vector localForce = vector(0.0, -f*Cd*cos(inflowAngle)+tipFactor*f*Cl*sin(inflowAngle), tipFactor*f*Cl*cos(inflowAngle)+f*Cd*sin(inflowAngle));

Source: Wiley Sons - Wind Energy Handbook .

[be_inspired]

In case the rotor plane would not be aligned with the mesh axis, the selection of cells using cellSet may not be "perfect". In some locations, we could have one cell, two cells or no cells for a specific radius and psi.

In some case, it is not easy to change the mesh for every rotor disk axis. So, how can it be solve? Is the rotorDiskSource prepared for those cases? The area_ of each cell is calculated but I do not understand completely the code. Sorry.

Updated: The bug about the coordinate system issue has been resolved on 2.3.x using a new tensor. I have not checked yet if the solution is the same

[GDTech]

Hi Marcelino,

Originally Posted by be_inspired

In case the rotor plane would not be aligned with the mesh axis, the selection of cells using cellSet may not be "perfect". In some locations, we could have one cell, two cells or no cells for a specific radius and psi.

In some case, it is not easy to change the mesh for every rotor disk axis. So, how can it be solve? Is the rotorDiskSource prepared for those cases? The area_ of each cell is calculated but I do not understand completely the code. Sorry.

I am using an external software for meshing (HyperMesh) in which I define my cellZones whatever their orientation are.
But I think you should be able to do the same with snappyHexMesh using refinementCylinder.

Originally Posted by be_inspired

The bug about the coordinate system issue has been resolved on 2.3.x using a new tensor. I have not checked yet if the solution is the same

Nice !
I will test it soon.

Laurent.

[be_inspired]

Hi Laurent,

I usually use ICEM HEXA for meshing but due to the fact that I want to use this code for wind turbine simulation in complex terrains/ wind direction, I would not want to change the overall grid for every wind direction/rotor misaligment.
I will give a try to snappy or foamyHexMesh.

Please, it would be great if you could you give us some feedback about the R() tensor and localForce vector issues? Post#4

[GDTech]

Originally Posted by be_inspired

Please, it would be great if you could you give us some feedback about the R() tensor and localForce vector issues? Post#4

In OF 2.1.x and 2.2.x, I noticed that localVector() and globalVector() functions did not produce expected results. So I replaced them by to manipulations :

vector Uc = coordSys_.R().T() & U[cellI]; => rotation and translation to local coordinate system (cartesion to cartesian)
Uc = Rcyl_[i] & Uc; => rotation to the cylindrical coordinate system (cartesian to cylindrical)

Note that Rcyl is different for each cell in the rotor cellZone since each cell has a different theta ...

It is the same operations in reverse order to convert back local force into global coordinate system.

Hope this helps.
Laurent.

[be_inspired]

Hi Laurent, All:

I have been running a wind turbine simulation and making some comparisons with a Blade Element Code. When running with a TI=10%, the forces distribution are quite similar to BEM (1% lower) but when running with a TI=1% ( keeping turbulent length scale and wind velocity), the power is lower by 20% approximately wrt BEM.

Did you see this issue or do you think about why this could happen?

UPDATED: http://www.cfd-online.com/Forums/ope...tml#post495673

Because forces are applyed directly over cell centers, it seems like it could created wiggles on the U and p field near the cell of interest.

Best Regards
Marcelino

[be_inspired]

Could someone help me to implement body forces in a different way to the conventional approach ( Ueqn)?

[jgil9]

Hi Marcelino,
Would you be so kind as to point me out to a tutorial or example to set up the rotorDisk, I am also traying to work out how to use rotorDisk to model a helicopter main rotor.
Thank you
Juan Carlos

[matace]

Hi,

I am trying to use the rotorDisk from openfoam 2.3.x but get wrong solutions.

Firstly, the resulting rotorforce vectors seems completly wrong if the rotor is not in the direction of the Z axis.

Secondly, if the rotor axis is the Z axis, the axial component (Z) of the rotorForce seems okay'ish. But,the drag component of the rotordisc is not good on both X and Y as the picture attached shows.

I have read the starting of the thread describing errors in the shift from the cartesian global coordinate system to the local cylindrical coordinate system, but it seems the code changed since then. It is now done through the following line in the rotordiskSourceTemplates.C:

            // velocity in local cylindrical reference frame  
            vector Uc = localAxesRotation_->transform(U[cellI], i);

localAxesRotation being fed only an axis and an origin, I guess is only does a rotation? Isn't there a mistake somewhere?

thank you,

[wurst]

Hi all,

I'm trying to use the rotorDiskSource to simulate a propeller for tank mixing (~100,000L). Has anybody used it for similar simulations or are there concerns why it couldn't be used for it? Simulations are already running in simpleFoam but I'd like to get transient solutions in twoPhase simulations with interFoam also. Any shared experience would be greatly appreciated.

Cheers!

[crusen mind]

Originally Posted by jgil9

Hi Marcelino,
Would you be so kind as to point me out to a tutorial or example to set up the rotorDisk, I am also traying to work out how to use rotorDisk to model a helicopter main rotor.
Thank you
Juan Carlos

hello carlos
I am also stuck at the same issue. If you know how to simulate a propeller case please help me.

[lethu]

Originally Posted by wurst

Hi all,

I'm trying to use the rotorDiskSource to simulate a propeller for tank mixing (~100,000L). Has anybody used it for similar simulations or are there concerns why it couldn't be used for it? Simulations are already running in simpleFoam but I'd like to get transient solutions in twoPhase simulations with interFoam also. Any shared experience would be greatly appreciated.

Cheers!

Hi wurst,

I am attempting to do the same simulation. I am investigating three options to do so : adding a source term, actuationDiskSource ou rotorDiskSource.

Have you managed to do it ? If yes, what was your strategy ?

Thanks for sharing !