Rotor Torque Prediction
I am studying a hydropower turbine using pimpleDyMFoam and AMI. A quick sketch of the setup is attached, however, this is just a simple model to replicate my larger problem.
I know that the fluid acting on the rotor will cause it to rotate anticlockwise around the x-axis when viewed along the positive x axis from the origin as shown, until the rotor reaches a certain free rotation speed, at which point the net torque on the rotor will be zero (Mxx = 0). A pressure plot is included indicating the high pressures on one side of the blades. As the rotor rotates faster and faster in the fluid the relative velocity between the moving fluid and the rotor blade surface will tend towards zero and thus the dynamic pressure created at the blade will tend to zero. To account for these moving blades I have additionally used the rotatingWall boundary condition.
When I run the solver in ‘locked’ mode, ie I specify zero rotation of the rotor in the dynamicMeshDict and zero rotatingWall boundary, I obtain a torque on the rotor for Mxx which is negative (right hand rule, thumb in +ve x-direction, positive torque is clockwise). So far so good, a negative Mxx will cause the rotor to rotate anticlockwise if the rotor was allowed to rotate. The torque magnitude is also in the right ball park so I am happy.
Next I set the rotor to rotate a little in the anticlockwise direction, my understanding is that the torque will decrease to zero as I increase the rotor speed anticlockwise due to the decreasing relative velocity and dynamic pressure above. However, OpenFOAM reports that the torque increases in magnitude (and is still negative).
Conversely, if I set the rotor to rotate a little in the clockwise direction OpenFOAM reports that the torque decreases in magnitude and will hit zero net torque at a certain rotor speed eg somewhere between +200 and +300 RPM as shown in the results graph...I haven’t pinned it down exactly yet but I do know from experiments that a similar rotor of this diameter will freely rotate around 230 RPM…..this also makes me happy. However, the rotor is now rotating in the wrong direction with zero net torque.
My questions are …
1) a) Has anyone experienced this and if so what was the problem?
2) b) Am I reading this correctly? Or is it possible that the forces/torques contribution from the rotating rotor and the pressure/viscous forces been summed incorrectly somehow in the code?
Any advice would be highly appreciated…my mesh is quite large but I could setup a simpler blockMesh case if that would help, please let me know.
Many thanks in advance
Change Direction of Rotation
Hi Jason and Foamers comunnity,
It's been some time now since you worked with this model. I hoped you could solve it. I would like to ask you a Question about your model and your procedure.
How did you change the direction of the rotation of the Mesh ? Should one introduce a negative angular speed or just change the direction of the axis of rotation ,say (1 0 0) to (-1 0 0) ? I'm working with pimpleDyMFoam and I haven't been able to get a rotating mesh or my turbine stays still while the whole domain rotates ( it's crazy, I know ..) even though I'm following the pimpleDyMFoam/propeller tutorial.
How do you calculate the Torque on your turbine when you finish the simulation with pimpleDyMFoam ?
As for your question: may it that the torque that you get is the reaction torque acting on the air ?
Sorry for the delay in replying, been a hectic week.
See this post I just made for one type of example http://www.cfd-online.com/Forums/ope...tml#post560643
And also, this simple case attached for pimpleDyMFoam. The direction of the mesh movement if you have it setup correctly is purely a + or - for the omega value. You have to specify the cellZone that is rotating, in this case the cellZone is called "rotor" and contains all the rotor cells and was previously setup using the preprocessing tools. This can also be done on the fly in blockMesh as you generate the rotor mesh (see blockMesh file). Be careful about setting the axis as this is the axis the mesh rotates around and also the origin as this is the point the mesh rotates around.
motionSolverLibs ( "libfvMotionSolvers.so" );
// new method in OF 2.2.2
origin (0 0 0.6);
axis (0 0 1);
omega 5.24; //rad per sec = +50 rpm
The torque is output automatically if you switch on the function forces which you do in the controlDict - see the functions at the end of the file, be careful of specifying the correct patch, density and the COG as the forces output corresponds to the COG.
Example output in the postProcessing directory is:
# CofR : (0 0 0.6)
# Time forces(pressure,viscous,porous) moment(pressure,viscous,porous)
0.00025 ((0.00945082 0.229273 9569.17),(-0.000115894 -2.18429e-05 144.667),(0 0 0)) ((0.323281 0.134849 1232.03),(-8.93156e-05 1.73033e-06 -7.75084),(0 0 0))
where the forces and torques are listed in the order shown at each time step...((pressure force X, pressure force Y, pressure force Z), etc etc...
You also have to ensure you set the correct boundary conditions for U for the rotor which is:
value uniform (0 0 0);
This tells the solver that the wall forces should be corrected for rotation I think and then you get the correct output. This is not required for MRF as fixed value of zero should be used.
I compared MRF and AMI and the result is more or less identical.
http://www.cfd-online.com/Forums/dat...BJRU5ErkJggg==Torque and Force Comparison attached
Thank you very much for your answer Jason !! I'm sorry for my delay in replying too.
It is surprising how light your model is. In my case I use many more applications like snappyHexMesh (to work with .stl files), createPatch, Toposet and series of them. If you don't mind I'll try to imitate your configs of ControlDict, fvSolution, fvSchemes and so on to be able to get my model running. In the moment I get always floating point exceptions and I guess it might be because either of my System definitions or my Mesh.
I have one silly question for now. The post processing directory that you mention doesn't appear in your folder. Did you eliminated it on purpose before sharing or it gets cleaned with a command such as ./Allclean and it is created when you run the program? When I run pimpleDyMFoam I just see the forces results in the log of the solver.
The model was only a demo, I would probably be using much the same as you for something more complicated ... but blockMesh is pretty powerful if you can get away with it.
Just unzip, type blockMesh and then pimpleDyMFoam and a folder named postProcessing should be created, in it should be a file called forces.dat which lists the requested forces and moments (relative to your controlDict function).
I am facing exactly the same problem with an MRF simulation. I am trying to simulate a turbine that has incoming angular velocity of water in clockwise direction (when viewed from the top) , so with correct blade angles, if I set the rotation velocity in 'minus' direction, the torque on my rotor should be negative (clockwise) if my axis is in positive z-direction. It turns out that the torque is positive and much larger than expected (it seems as if the rotor is trying to rotate in the opposite direction against the motion of the incoming water, which explains the much higher torque - though i am not sure as I cant visually verify the motion direction in the MRF simulation). However the direction of torque is still wrong. Conversely, If i set the rotation of the MRF zone in opposite direction, I get all the right torques in both magnitude and direction.
Did you already solve the problem of the wrong torque direction, or is it a possibly a bug? Also, in MRF simulation, after fvOptions were implemented , do we still need to specify the interface between the rotating cellzone and the rest of the domain as a non-rotating patch?
My fvOptions dictionary and force-calculation parts of controlDict are as follows:
|All times are GMT -4. The time now is 06:56.|