August 08, 2024:

 

I've spent the last 16 years working on PROP_DESIGN. My time, working on the project, has come to an end. I released the code as public domain software, so you are completely free to do whatever you like with it. Below are my thoughts, for software developers looking to improve the project.

 

Note that, I'm not a software developer. I'm a retired aerospace engineer. I had one programming class in Fortran 77. So real software developers will see the many problems with my methods. In college, I got very interested in aircraft propeller design. It was very difficult to even find out how to design an aircraft propeller. I wanted to make that easier for people. Since I spent a lifetime accumulating knowledge on the subject, I wanted to pass that on to people. In any event, real software developers could make a lot of useful improvements to PROP_DESIGN.

 

The only thing I ask is that you call your program something other than PROP_DESIGN. This will remove any confusion between what you create and what I created. Moreover, having many different programs go by the same name would be a nightmare.

 

Sincerely,

 

Anthony Falzone

 

Programming Language:

 

I coded the project in Fortran 77. The main reason for this was it's the only computer language I know. Another reason was it's historically significant. Previous propeller design codes were also coded in Fortran 77. So, the idea was, to give people an idea of how things used to be done. That being said, a new language would be beneficial. The reasons for this are below.

 

Code Reuse and Maintenance:

 

There is no code reuse right now. I simply copy and paste the source code needed into other versions. This makes maintaining the software very difficult. It is also inefficient in many ways. The geometry code 'XYZ' and the 'ANALYSIS' code could be standalone libraries that were called as needed.

 

This approach would make maintenance much easier. 'OPT', 'STATORS', and 'MAPS' would become very small, since they would just make multiple calls to 'XYZ' and 'ANALYSIS'. This approach would also allow for the creation of more types of performance maps. For instance, you would be able to input multiple operating conditions, to simulate real life climbs. Right now, you have to do that manually, using 'ANALYSIS'. Then create the plots yourself.

 

Parallel Programming:

 

Parallel programming didn't exist when I learned to code. Now that it does exist, it would be wise to utilize it. 'MAPS' should be able to run in parallel without too much trouble. The performance gain should be 8x, if 8 cores were available. 'STATORS' could also run much faster in parallel, if enough cores are available. Currently, 35 cores would be needed. Previous versions would have needed 39 cores. It would be harder to get 'OPT' to run in parallel, due to how it determines when an optimum design is found. Another thing to consider is 'OPT' and 'STATORS' use the same pitch search schemes. The cruise pitch search is currently done in a serial manner. However, the takeoff pitch search should translate to parallel. Thus, the cruise pitch search could be switched to a scheme similar to the takeoff pitch search. All of the codes read and right data in a serial fashion. So that would have to be addressed as well.

 

Output CAD Models:

 

This isn't something that I know how to do. PROP_DESIGN_XYZ outputs points files. The point files are used to manually create CAD models. Recent code updates have made this process much faster. However, it would still save the user time, if complete CAD models were output.

 

GUI:

 

New users would probably appreciate a GUI. The old school way of doing things isn't known by younger generations. PROP_DESIGN uses the old school way.

 

Better Plotting:

 

PROP_DESIGN uses Gnuplot. Unfortunately, Gnuplot is slow and has poor 3D view controls. Using a better plotting library would be helpful. Having the library built in, rather than a 3rd party download, would be useful also.

 

Database:

 

It would be a good idea to read and write everything to a database of some sort. This way, there aren't a ton of files in a folder.

 

Windows Installer:

 

I like that PROP_DESIGN does not need an installer. However, this probably confuses a lot of new users. Most Windows users expect a *.msi file to install/uninstall the program.

 

Greater OS Support:

 

Native support for Linux and Mac would probably be useful to some people. The existing code should be able to run on any OS and/or CPU. However, it would have to be compiled by the user, using a compiler that supports Fortran 77. So, it's added work, for those not using a x86 processor and Windows.