How My Python Code Resisted the Rotation of the Designed Variable-Pitch Propeller
August 9, 2026
Developing a variable-pitch propeller design tool turned out to be a journey filled with both excitement and frustration, even though it was based on a working fixed-pitch propeller design code. What started as a seemingly straightforward task of editing an existing Python code, quickly evolved into a complex engineering project with numerous technical hurdles.
The three major headaches I struggled with were:
1. Thick airfoil optimization
At this moment, I cannot design efficient airfoils with a minimum thickness greater than 16%, which is sometimes required to ensure a safety factor of 2 for all blade sections. To overcome this, in the current version of the code, I force the increased thickness for an airfoil after optimization, which is not the correct way to do this. And this also introduces the challenge of propagating the manually changed geometry throughout the huge codebase.
Next time, I will try a thicker baseline airfoil for optimization. This would allow the optimizer to work within the correct constraints from the start, rather than patching the geometry afterward.
2. 'Rotation' of the designed propeller for performance estimation
Unexpectedly, I struggled with 'rotation' of the designed loaded propeller to estimate its performance at a series of pitch angles, using the respective methods from the design class.
Current workaround:
I rely on the propeller 'rotation' results obtained inside the design code. This is not ideal, as it limits flexibility and makes the workflow less modular.
What I learned:
A possible solution is to create a separate notebook for variable-pitch propeller analysis. This would allow me to:
3. Structural analysis inconsistencies
Structural analysis does not work if it uses BEM method from the design class. Currently, I have no ideas why, but the issue will be fixed.
It was really hard, with all other projects and responsibilities. But now, we have one more working, quite reliable, and versatile code, which makes me proud and happy.
The three major headaches I struggled with were:
1. Thick airfoil optimization
At this moment, I cannot design efficient airfoils with a minimum thickness greater than 16%, which is sometimes required to ensure a safety factor of 2 for all blade sections. To overcome this, in the current version of the code, I force the increased thickness for an airfoil after optimization, which is not the correct way to do this. And this also introduces the challenge of propagating the manually changed geometry throughout the huge codebase.
Next time, I will try a thicker baseline airfoil for optimization. This would allow the optimizer to work within the correct constraints from the start, rather than patching the geometry afterward.
2. 'Rotation' of the designed propeller for performance estimation
Unexpectedly, I struggled with 'rotation' of the designed loaded propeller to estimate its performance at a series of pitch angles, using the respective methods from the design class.
Current workaround:
I rely on the propeller 'rotation' results obtained inside the design code. This is not ideal, as it limits flexibility and makes the workflow less modular.
What I learned:
A possible solution is to create a separate notebook for variable-pitch propeller analysis. This would allow me to:
- Keep design and analysis concerns separate.
- Use consistent assumptions throughout the analysis.
- Easily experiment with different pitch angles without affecting the design code.
3. Structural analysis inconsistencies
Structural analysis does not work if it uses BEM method from the design class. Currently, I have no ideas why, but the issue will be fixed.
It was really hard, with all other projects and responsibilities. But now, we have one more working, quite reliable, and versatile code, which makes me proud and happy.
