Hi,
Im pretty sure ive got to grips with all the code, except for changing the blade number. Ive run the case with 6 blades and its giving accurate data, and Ive got to grips with paraFoam and the force/power file. I can change all dimensions that I want, and got it set up perfectly, except for the blade number. My mesh is fine with the four blades, no errors come up. But when I run ./parallel it throws up a few errors. I have edited the dynamicMeshDict like you said. Ive also done quite a bit of changing things around in the case directory to make it work. Ive tried to remove all reference to 6 blades, removing all places with blades4 and blades5, but it still throws up errors that I cant figure out. When you change the number in the mesh, and the dynamicMehDict, does it work strait away? with 4 blades instead of 6. |
Ah, one more thing.
In 'fixBoundary' you have to edit it to exclude the inclusion of the 2 additional blades. It is at the bottom of the script. You can replace the following section: Code:
lines=$(grep -n "bladeAmi" constant/polyMesh/boundary | cut -d: -f1) Code:
lines=$(grep -n "bladeAmi" constant/polyMesh/boundary | cut -d: -f1) Also in the mesh, in main.geo, be sure to comment out the lines referencing bladeAmi40,50,41, and 51. |
Excellent, thanks. Ive got it all working with four blades, and correct dimensions for my project. Just a couple more questions:
1. In the Blades part of the mesh, youve got a function to produce NACA aerofoils, are you not using this function? The mesh doesnt look like a standard NACA shape, and I cant see in in use in the code apart form in the part you have commented out in the 1_points.geo. Is it a case of replacing the part above it with the commented part? Im getting lift and power lower than I was expecting and I think its probably because of the shape of the aerofoils |
For the time being, ive found the bit that adjusts the curvature. That way ou dont have the cmaber working the wrong way at the bottom
Edit: I think actually it could be closer than I thought. With the maximum angle of attack directly upwards you get a fair amount of horizontal force. Im going to try and counteract that tomorrow by applying a slight change to the direction of thrust, slightly clockwise. I think ive spent enough time in your code to figure out how to do this, it should jsut be the mesh that needs changing and nothing in the case? |
At one point I was using the NACA airfoils, but without the inflation layer. If you really wanted to, it would not be terribly difficult to implement. Gmsh uses a simple C-based language, and the mesh is quite simple and 2D.
Be sure you have run the simulation at sufficiently low maxCo!!! (in the controlDict) lower maxCo = greater accuracy! maxCo = 2 should be sufficient. I believe the default in the case files is maxCo = 30. The results will probably change significantly when you go to maxCo = 2. To reiterate, the pitching schedule is sinusoidal. This approximates the schedule that results from the multibar spoke-like mechanisms that are common in cyclorotors. The amplitude of the pitching is specified in the dynamicMeshDict in variables 'min' and 'max' for every blade. Be sure these match your case. To vector the thrust, change the tilt variables in the mesh and in dynamicMeshDict. |
Hi lordvon,
I want to thank you again for this, its an awesome bit of code. Ive got it all working, and modified to my situation. Ive also manufactured a cyclorotor of my own and Ive got lift and power data with which to compare to the CFD; hopefully it comes out as well as the predictions on your blog. Just one more little bit, when running the f file you give the units of force as N/m, is this a typo? Or do you mean N/m of span length, if so, what's the point in changing the span length in the code? Also, do you have a name for me to reference and acknowledge in my report, or would you rather be named as lordvon? Thanks, Tom |
Glad I could help. That is very cool that you built a physical model; I am looking forward to seeing your paper when it becomes available!
Yes, N/m would be a typo. It is consistent if the variable 'span' is absent or equal to 1. I added 'span' later and forgot to delete '/m' from the text display. The forces are calculated by first normalizing per unit span, then simply multiplied by 'span'. So the resultant calculated forces and powers are proportional to 'span'. If you changed the cell depth in the mesh be sure to change it in 'cellDepth' in the 'f' script. To check what your cell depth is, you can run checkMesh and the non-zero z-value for bounding box will be it. Another note, the 'average' values displayed are the averages of the plots you see. So you should take the average as the correct value if the plot mean settles and is not ramping up or down. You can control how much of the recorded time is plotted by 'cutoffFraction'. you may have already known this, but I just wanted to make sure. Thank you for giving me a mention in your report. You can use my real name, Robert Lee. |
Hi Tom,
How were the results? |
1 Attachment(s)
Hi Robert,
Sorry for the delay. The results are good (ish); Ive got to do a little fudging and the results come out really nice. First thing is the force and power come out 4x smaller than measured. I think that this comes from the fact im using a 400mm span, and thats where the 4 is coming into it. Or maybe I changed the mesh depth a little. I havnt looked thoroughly into the code to check but I know where to look. But running over different speeds and angle of attacks the 4x is constant, so I think there is something in the code. The Power on the experimental set-up has an offset of 27W compared to the CFD. This can be accounted for in the fact that this power also goes to the servo's and inefficiencies in the motor and bearing; for a set RPM the offset in constant over all angle of attacks. Once the offset is taken out, and the 4x is included, the data matches perfectly. The lift data is in the right region but it doesn't follow the same trend as the experimental. I never got the NACA data implemented, so I think thats where these differences come into it. If I have time ill re-look into trying to implement the NACA aerofoil but for the time being the results look pretty nice. Ive uploaded the three graphs; lift, power and lift to power ratio. The set-up used was: 4x aerofoils 100mm chord aerofoil 400mm span 400RPM 150mm Radius |
Did you use the 'f' file to get the performance figures? Can you post it? I can see if it is consistent with your experimental parameters.
|
1 Attachment(s)
Ive attached the f file. The only thing Ive changed is the span to 0.4 and the omega to 41.888 (400RPM)
|
It seems consistent, as long as you didn't change cellDepth in the mesh file, which I don't think you did because there is no reason to.
I do not think there is reason enough to fudge the numbers... I am sorry the results did not come out as well as you wanted. I did not look at the scale of the power and lift until now, and I really think that the level of lift and power are very small. Perhaps the simulations are more accurate in the regime of high power loading. If you look at the graph in my blog post, if you zoom in on the data point with lowest power, you can construe this to be an inaccurate simulation. But the higher the lift and power loading (the useful simulations), the more accurate the simulations become. I really think if you did a higher rpm, the results would be more accurate. (it looks like you did one rpm and changed the pitch) There are a lot of interesting things that occur in experiment that is less than ideal. One example is the significant bending of the blades due to centrifugal forces so that the effective pitch is lower than that apparent on the blade. This is noted to have significant detrimental effects in papers by Moble Benedict. It would not explain your particular discrepancies, though, but it is good to be aware of such possibilities. The only troubleshooting I can think of right now is to make sure you let the forces and power figures settle down; i.e. let them run for a long time to be sure the average stays reasonably constant. Due to the boundary condition setup, the forces and powers take a while to settle. In my experience, the average has some asymptotic behavior and changes a significant amount. |
Hello all,
Firstofall, Robert, thanks for your work. The video on youtube looks quite interesting. However I have problems compiling the code and would appreciate some help. These are the steps I took: 1) Download the zipped OpenFOAM_Additions-master folder and extract it 2) Open Terminal and go to the cycloRamp folder 3) Enter the following commands as described in the INSTRUCTIONS file: Code:
sudo Code:
chmod +x remake Code:
./remake Code:
kate@linux-sb34:~/OpenFOAM/kate-4.x/run/lordvon/OpenFOAM_Additions-master/cycloRamp> sudo Best regards, Kate (I'm running OpenFoam 4.x) |
Hi Kate,
It's always great to see people working on these interesting concepts (even though it's my personal opinion that cyclorotors are generally impractical, but hey, that heavily depends on the use case!). You'll notice that I made that post 2 years ago; compatibility is (slightly) broken between even the latest OpenFOAM 2.x and the earliest 3.x. Now, with v1606, I believe it will be broken even further. By the way, what is this OpenFOAM v4 you are referencing? I haven't heard of it. Unfortunately I do not have the time right now to convert the case (I don't even have a Linux box at the moment). So, the only thing I can suggest is to ask around for help. Sorry, but good luck with your endeavors and be sure to update us! |
Hi Robert,
thanks for your answer! No problem, I'll try it myself. I just thought mayhaps somebody had solved this problem already. OpenFOAM 4.x is the newest release afaik.?? What is v1606 you are referencing? Best regards, Kate |
Hello Robert,
I am running your code on OpenFOAM 2.2.2 now and it works perfectly. However, I am trying to plot the blade0 forces over its actual position. Would you mind to explain in a view words how you are calculating the quaternion rotation in your cycloRamp.C file. I don't get the following part: Code:
quaternion R(0,0,azimuth.z()); // I think you are refering to the quaternion.C file here. I think 0, 0, azimuth.z() are the Euler-angles. What is R? Code:
solidBodyMotionFunctions::rampedAxisRotationMotion::transformation(): Time = 37.340491 transformation: ((0 0 0) (0.99645632 (0 0 -0.084111854))) As you can see, a big part of the problem is my lack of understanding in the field of quaternion rotation. Any advice would be appreciated. Best regards, Kate |
1 Attachment(s)
Hello again,
for everyone, who's interested, I've solved my little problem. You can calculate the corresponding Euler-angles with the attached script. Best regards, Kate |
All times are GMT -4. The time now is 06:54. |