The 'PROP_DESIGN News' page lists 'recent' changes regarding all downloads provided on this site:
- The primary download is located on the 'Download' page
- My Fortran compiler tests are located on the 'Fortran Benchmarks' page. This is an optional download
- Programs that include vortex interactions are located on the 'Vortex Interactions' page. This is also an optional download
I've tried keeping a changelog several times. However, due to the vast amount of updates, they quickly became way too long. Instead, I keep a list of the most 'recent' updates below.
09/06/24:
Updated the Fortran benchmark download. The updates are discussed below.
- I recently learned of a new Fortran compiler called LFortran. I tried it out today. Unfortunately, it's not working with PROP_DESIGN. Since I was having issues with it, I tried two different
ways of installing it with MSYS2. Both ways of installing LFortran yielded the same results. However, that led me to test flang again, as it also has two different ways of installing it with
MSYS2. I found that one install method may be better than the other. I did get a decent performance improvement. However, flang was also updated. So the improvement could be from that or it could
be from the install method. I'm not really sure, but I liked what I saw. So I switched how I install flang now. In any event, gfortran also had an update. So I reran all gfortran tests as well
- As mentioned above, today's results use the latest versions of gfortran and flang. However, Intel Fortran is one point release back. I didn't want to risk messing anything up by upgrading it.
Upgrading Intel Fortran is a long crappy process. It's not easy like MSYS2. Also, Intel is going to stop providing ifort, very soon. So if I do update the Intel Fortran results, it would be after
they switch to ifx. Therefore, my Fortran benchmark would have all of the ifort results removed
- I added some new files relating to LFortran. However, I didn't go into any depth with it, as it failed right out of the gate
- I added some information regarding MSYS2
- I fixed a few minor typos in places
There is only really one Fortran compiler option for me. That is ifx. ifort will soon be discontinued. ifort, gfortran, flang, and lfortran all have odd bugs. gfortran and flang cause PROP_DESIGN
to run much slower than ifx and ifort. The biggest problem with flang is static builds haven't been working for awhile. So even if I wanted to, I couldn't distribute my codes like that.
gfortran also has a history of breaking the static builds feature. Thus, ifx is the clear winner, as far as PROP_DESIGN running on Windows is concerned. I imagine the situation would be the same
for any operating system that ifx supports.
08/24/24:
- Updated the Fortran benchmark download. Added some information, regarding compiler bugs I found recently, to the 'Fortran Compiler Results' spreadsheet and *.pdf file. I only added
information to the spreadsheet. I didn't rerun all of the tests, as the Fortran compilers hadn't changed enough to warrant it
08/23/24:
- Very minor updates to the primary download. There was a source code note, in STATORS, that got a little corrupted (during a previous update to the note). I fixed that today. I also updated
the documentation in the 'Stator Optimization' folder. I tried to make the information a little more detailed and easier to understand
06/23/24:
- Added some additional information to the Fortran benchmark download
06/22/24 Update 2:
This update only applies to the primary download.
- I updated the AIRFOIL_AND_STALL_MODEL_DATA *.dat file names. This particular program operates a little differently than the other codes. The original file names were misleading. This change
required updates to all of the *.plt files in that folder
06/22/24 Update 1:
This update applies to the primary download and the vortex interactions download
- Updated many of the plot titles for ANALYSIS and ANALYSIS_MESH_TEST_TWO. This was for consistency and clarity
06/07/24:
- Added a plot to the Fortran benchmark download
06/06/24 Update 3:
- Minor code refactoring performed on the MAPS based programs
- I downloaded the latest version of Intel Fortran and updated the Fortran benchmark download
- I've been testing the Fortran compiler issue I discovered on 06/01/24. It turns out that ifort also has the issue. However, for ifort, it's not optimization level that triggers it. It's
switching from SSE3 extensions. It's also very small for ifort, extremely large for flang, and actually helps gfortran. However, gfortran still performs worse than it should. The only compiler
that worked properly was ifx. ifx also performed the best. For the most part, ifort performed the same as ifx
- Lastly, I updated all c.bat files. They now use the ifx Fortran compiler. Intel is killing off ifort. So, switching to ifx was inevitable. This moves the CPU support date up from 2000 to
2004. Basically, ifx only goes back to SSE3 extensions while ifort goes back to SSE2 extensions. The upside of using ifx is the programs run a little bit faster now. As always, you can experiment
with recompiling the programs. You may be able to gain a little more speed, by targeting your specific processor. However, this is optional and not likely to gain very much speed
06/02/24 Update 2:
- I tested Gnuplot 6.01 and it seems they've finally fixed the 2d zoom issues with the wxt terminal. The last version that had a working 2d zoom was 5.2.8. I think it's safe to update your
Gnuplot installation now. I took advantage of their new contourfill option. This only applies to two plots, located in the AIRFOIL_AND_STALL_MODEL_DATA folder. I left in the old method, that used
pm3d, in the *.plt files. So if you have an old version of Gnuplot, you can switch the plots back to that. You just change which lines are commented out, in the *.plt files. The files in question
have 'Color Contour' in their names
- Given all the code updates, it was past time to update the hovercraft and vtol examples. The examples are referenced on the website and in the user manual as well. So all of those references
got updated
06/02/24 Update 1:
- When I changed some of the example names, I should have also updated the screen output of XYZ. This is fixed now
- I updated all of the example files, so that they match the latest solver settings. The only differences were beyond the iteration tolerances. So it wasn't a big deal. However, it may have
caused confusion, if I left it that way
06/01/24 Update 2:
- I found an issue with the latest versions of gfortran and flang. It seems they are losing precision depending on the optimization level used. This was causing convergence failures, because
they were taking longer to converge than they should have. To combat the problem, I increased the amount of iterations that are allowed. The Fortran benchmark download has more information, if
interested
- Updated the Fortran benchmark download. I added information, to the results spreadsheet, regarding the issue mentioned above
06/01/24 Update 1:
- I updated the solver tuning again. This was to get rid of a convergence failure, for one example (MAPS IFS = 2)
- I meant to deactivate the quick fix, for the stall model Cm curve fit, from all the codes. However, I had only did that for two of the codes. I have the quick fix deactivated for all of the
codes now
- Some of the new airfoil model Cd curve fits didn't get entered in right. I missed a few of the E exponents. Those are all supposed to be D exponents, for double precision Fortran 77. This is
fixed now
- During a recent update, I had moved the FAMS variable to a different location within the initialization block. This inadvertently changed it's definition from an integer to a real number.
It's supposed to be an integer. This is fixed now
- I fixed some old source code notes. When I put them in there, I had copied one note to multiple locations. I didn't realize that when I did that the note needed a slight modification. It
would lead to confusion the way it was. This is fixed now
- I meant to copy a source code note, that I added to AIRFOIL_SIM, to all the codes. However, I forgot to do so. This is fixed now
- I added min and max Reynolds number to some of the codes. This is so you can get an idea of the range that PROP_DESIGN is operating in. For the built in examples, the average Reynold's number
for all the cases is pretty close to the wind tunnel data Reynolds number. That's a good thing
- I updated the 'Airfoil Wind Tunnel Data' spreadsheet
- I updated the user manual, to include the new solver settings
05/31/24 Update 2:
- I forgot to update the PEAKLD variable in ANALYSIS and ANALYSIS_MESH_TEST_TWO. This value dropped by roughly half, due to the recent Cd curve fit updates. So, the release from earlier today
will have airfoil efficiency plots that show roughly have of what they should
05/31/24 Update 1:
- The last few updates highlighted a problem with the airfoil Cd curve fits and the stall model Cm curve fit. This release fixes both of those things. The Cd curve fit updates drastically
change the propeller/fan performance. The peak LOD is drastically reduced and occurs at a higher effective angle of attack now. It also occurs at a slightly lower effective velocity. There is
also a broader range of effective angles of attack that have good performance. Overall, you can absorb more power now, which lets you generate more thrust. However, propeller and fan efficiency
is lower than before. The A400M example took a big hit to efficiency. The effective velocities, for that example, are very high. They're in a range where the drag coefficients increased. The good
news is the updated curve fits match the data very well. So they won't need to be updated again
- I had to retune the solvers again and update all of the examples, due to the curve fit updates
- I reduced the initial ROCR range that STATORS searches, to remove convergence problems with one example
- I made improvements to the screen output of STATORS, to make it clear when an optimum design is not found
- I removed the Mathcad files from the AIRFOIL_AND_STALL_MODEL_DATA folder
- I improved some of the plots in the AIRFOIL_AND_STALL_MODEL_DATA folder and removed some unnecessary ones
- I updated some files, added some files, and removed some files from the AIRFOIL_AND_STALL_MODEL_DATA folder. This was all related to the curve fit updates. I left the previous curve fits in
the files. It was easier than removing them and I figured it could be useful to keep around. Just to show what not to do, lol
- Today's update changed the performance so much that I needed to rename some of the built in examples. I also changed the running order of them
- There is one can of worms that I can't do anything about. It's pretty obvious that the two sets of airfoil wind tunnel test data do not agree with each other. One has much higher drag values
than the other. This makes me question how good the data is. The bigger problem is, how to process the data, when it overlaps. Previously, I averaged through both sets. Now that I see how
sensitive the propeller performance is to the curve fits, I tried to pick which set of data seemed more accurate. I went with the data that had higher Cd values. It's just purely a guess, on my
part. Neither set of data may be correct. I have no way of knowing
- I added some examples to the ANALYSIS folder that show negative AoAs in action. The tips are making negative thrust and pushing the air the wrong way. I've done those type of tests before but
I never left the files in there for you. If you run the A400M example, as is, I have it setup to show negative AoAs in action. There are additional files in there, so that you can switch the
example up and run it different ways
- This update also made me realize that I never mentioned anything about solver tuning. Basically, if you update the airfoil and/or stall model, you need to retune the solvers. Code changes
could also require a retune. The pitch search settings are not exposed, but sometimes those require retuning as well. None of this should matter, for a typical user. However, if you get into code
modifications, then you should be aware of this
Below, is a picture showing how the performance has changed, due to all the recent updates:
05/29/24 Update 2:
- I was looking at website images, that I had posted for the 05/09/24 update, and noticed a bug that I previously fixed had somehow reappeared. The bug is Cl, Cd, and Cm are not zero when they
should be. It has to do with numerical error. I had put in a fix to mask the problem, awhile ago. Not sure how, but the problem reappeared again. So, I fixed it again. The code is the same, I
just adjusted the tolerance for it. I also gave the tolerance a variable name. This way, if I have to fix it yet again, it will be easier to do. I had the tolerance at 1.0E-14. Today, I bumped it
up to 1.0e-12. This is one of the many unexpected benefits of the new AIRFOIL_SIM program. It brought to light a number of things that you would have never noticed previously
- The pictures for the 05/09/24 post have been updated, so the bug mentioned above, is no longer present
05/29/24 Update 1:
- I had made a last minute change to the 05/28/24 update, tested it in a few codes, then forgot to propagate it to the rest of the codes. This is fixed now. The change doesn't seem to have an
affect on anything. However, it makes the source code easier to understand. Also, making the codes as consistent as possible is a goal of mine
05/28/24:
- Fixed bugs introduced with the 05/09/24 update. I had to change a number of things and the results are a little different than the previous version
- Ever since I created MAPS, it has had an issue that I couldn't really do anything about. If one or more runs didn't finish, the plot legends would get corrupted. I found a way to fix that.
The legends now show the actual pitch values ran. So when runs are missing, the plots can still be understood. Unfortunately, the plot colors won't match normal runs. Also, the data file headers
will be missing, if the first run doesn't complete. Those aren't big issues though. As always, you want all eight runs to complete. If they don't, you need to change the inputs and rerun the
program
- Previously, the convergence was not the same for each propeller rotation direction. It should be the same. This is fixed now
- I made some changes to file and plot names, to make things more clear and easier to find
- In MAPS_CS, I moved the most important performance information into it's own file. Previously, if you didn't know where to look, you would have never seen it
- I added two new plots to MAPS_CS
- I made some small improvements to the screen output of OPT and STATORS
- When I switched to using the 'REPLACE' command, it was inadvertently applied to two files that it shouldn't have been. This caused two input files to be written over with empty files. This is
fixed now
- Added a new undocumented code called AIRFOIL_SIM. See the 05/09/24 post, for more information about the new program
- I expanded the operating range of the AIRFOIL_AND_STALL_MODEL_DATA program, to match the new AIRFOIL_SIM program
- Updated the Fortran benchmark download. You now have an option to set how many times you want to repeat the tests. Previously, it ran five times and reported the average runtime. Now, you can
run it anywhere from 1 to 5 times (the average runtime is still reported). The default is now 1. I also switched from using input file zero to input file two. These changes make the benchmarking
program run as fast as possible. This makes updating the results spreadsheet manageable
05/09/24:
- Made more changes, so that the source code is usable in more situations. One of the changes was to let the wake velocities have signs. This requires a sign convention. The sign convention has
always been the same. However, by keeping the values positive, the user didn't need to know what is was. I added a document to show what the sign convention is
All of the recent changes came about because I've been working on creating a new code. The code does all the same airfoil post processing as PROP_DESIGN. However, it does it for geometric angles
of attack of +/-360 degrees. PROP_DESIGN only operates from +/-90 degrees. The wider AOA range is what necessitated all of the changes. You can run the code with the default solver or enhanced
blade element theory (no induced velocities or induced angle of attack).
Below are pictures of what I've been working on. If I get the program in a state where it might be useful to people, I will upload it. Right now, it's just something I made to study some things.
It reuses PROP_DESIGN source code. So it takes Cl, Cd, and Cm data and processes it to determine the induced angle of attack and a wide range of propeller performance outputs. Rather than simple
airfoil inputs, it uses propeller inputs. So, for instance, velocity and rpm are inputs. It automatically runs from -360 to 360 deg. As opposed to 2D CFD software, this code runs extremely fast.
That's because it's not solving the physics. It's using wind tunnel data. That's the whole point of propeller design theory. Of course, if CFD was accurate, you could reuse that information.
Either way, propeller design theory is very compute efficient. Although the new code utilizes propeller design theory, it doesn't analyze propeller geometry. It analyses a rotating airfoil
section. It outputs useful airfoil and propeller performance metrics. So, things like L/D, prop. eff., fan eff., etc...
The animated gif file is automatically created, using Gnuplot. The blue arrows indicate air flow inlet and outlet directions. The red and green arrows are the thrust and torque force vectors.
Thrust will always be in the z axis and torque force in the y axis. The orange arrow is the lift force vector. The magenta arrow is the drag force vector. The small circle in the center is to
help indicate circulation direction. The small dot on the circulation circle indicates direction. Circulation follows the right hand rule. So if the dot is on the right it means circulation is
counter clockwise. If the dot is on the left, it means circulation is clockwise. You also have the ability to look at single frames (i.e. single geometric angles of attack).
05/06/24 Update 2:
- The update, from earlier today, needed a slight change. The two new logic statements for GAMNZ and GAMNZ2 weren't quite right. I needed to add an absolute value to each of them. This doesn't
affect any of the codes, in their current config. However, if you used the source code for other purposes, you could have noticed the problem
05/06/24 Update 1:
Made a number of improvements that don't affect any of the codes. However, if you used the source code for other purposes, you could have run into the bugs. These bugs are fixed now.
- Changed sign handling for the new circulation formulation (GAMNZ). It now follows the sign convention of the traditional circulation value (GAMNZ2)
- Added logic to recognize when GAMNZ should be zero
- Added logic to mask compute error for the Cl, Cd, and Cm coefficients. Moreover, all values are set to zero, when they return a value less than the absolute value of 1e-14
- Improved the airfoil and stall models, so that Cl, Cd, and Cm are zero when effective velocity is zero
- Updated the circulation notes page
- Updated the net force direction picture
- Updated the vortex interactions download. Removed two spreadsheets from the ANALYSIS_MESH_TEST_TWO folder. I had used these to debug the vortex interactions. The files don't need to be in
there. Removing them makes the download smaller
05/01/24 Update 2:
- Instead of outputting the rotated z direction points. I changed it to output the rotated nz plane points. This only applies to XYZ. These points are provided for reference purposes
- Streamlined some of the write statement format specifiers
- In the ANALYSIS folder, there was a shortcut that shouldn't have been in there. In fact, I have no idea how it got in there. It's removed now
05/01/24 Update 1:
- Updated how the tilt angle is used to calculate propeller performance
- Removed the THETAWD variable and associated plot. This was redundant, since it's the same thing as THETAPHIZ
This update should be the correct implementation of how I see tilt working. Unfortunately, the geometry is so insane that I can't get a very good grasp of certain things. So I'm not 100%
confident with this aspect of the code. Tilt is normally zero, so it won't come into play that often. In any event, here are some pics of the insane test geometry that I was working with. You can
create things like this with PROP_DESIGN. Of course, this is not a propeller you would want to actually build. I created it simply to push the math to the extremes. It's rather wild, though. It
looks like a vertical axis wind turbine. However, it's not. It's a highly swept blade, in a takeoff configuration, using a lot of constant speed blade rotation. It's probably best used by a 007
villain to chop off James Bond's head, lol. Of course, the villain would screw up. Rotate the blades in the opposite direction, while doing the evil laugh, and destroy his plane. It also looks
like the blades in a blender.
04/30/24:
- Fixed an issue with the XYZ dimension checks. If delta radius was negative, the DELR1 and DELR dimension checks would fail. This is fixed now
04/26/24:
- Code refactoring
- Updated the vortex interactions download. Fixed a bug with the trailing vortex interactions. When the rotation direction changed, the results weren't being computed properly. This is fixed
now. The remaining difference in the results has to do with the iteration tolerance and the number of wake steps. As you make both finer, the results get closer together. Currently, with the
default settings, the agreement is more than good enough
04/24/24:
- While debugging the vortex interactions, I inadvertently left an XYZ input file in a modified state. This is fixed now
- Updated the Fortran benchmark download. I added information to the results spreadsheet, to indicate that I tested the latest versions of gfortran and flang. I didn't observe any improvement
in runtimes, so I left the previous results in place. I added some additional info to the pacman text file
- Updated the vortex interactions download. I removed two CAD files that I left in the download. I created them to debug the vortex interactions. They aren't something you would need. Removing
them reduces the size of the download
04/23/24:
- Made a few small improvements to ANALYSIS and XYZ
- Re-released the vortex interaction codes as their own download. They are available on the 'Vortex Interactions' page. These
codes are optional
- Updated the vortex interactions download. When I added constant speed systems to PROP_DESIGN, it made the vortex interaction codes much more complicated. I thought I had it figured out, but
recently, I realized that what I tried to do wasn't working right. This is fixed now
- I also made a number of improvements to all of the vortex interaction codes, so that these codes are consistent with the primary versions of PROP_DESIGN
04/22/24:
- Code refactoring
- Minor documentation update
04/18/24 Update 2:
- Updated the 'Circulation' and 'PROP_DESIGN Theory' notes pages. They both became out of date, as the codes changed over time
04/18/24 Update 1:
- Fixed a bug related to three variables missing their array designation. This bug was introduced within the last few weeks
- The 04/16/24 update broke many of the plots in the XYZ folder. This is fixed now
- More code refactoring
04/16/24:
- Bug fixes and code refactoring
- Added more dimension checks
- The dimension check units have been changed to mm and degrees. They were in units of meters and radians (which is how they're calculated)
- Added a note page, regarding the dimension check tolerance
- Updated some of the XYZ output files
04/15/24:
This update is listed as 04/12/24 in the source code, as that's the date I started working on it. It took much longer than expected, as I had to track down a bunch of bugs that the code
refactoring caused.
- Code refactoring, to make internal variables more clear
- Fixed bugs that the code refactoring caused
- Improved PROP_DESIGN_XYZ output information and plots
- Updated the documentation, to match today's changes
- Updated the user manual title page image
- I removed three codes, in the undocumented folder, which included a feature from PROPSY. This feature was vortex interactions. It's one of the things that made PROPSY unique. However, I
applied a lot of bug fixes to this feature. Unfortunately, it's so complicated to debug, I never felt very confident with it. The feature is also questionable conceptually, slows the code way
down, and it usually doesn't affect the results very much. Since I spent so much time on the feature, and it's brought up in academia a lot, I left it in three undocumented codes. I plan on
debugging this feature more and re-releasing the three codes as an optional download
04/11/24 Update 2:
- Fixed an issue with the painted tips cut plane location. It should now be consistent, regardless of chord distribution choice. This only applies to XYZ
- Fixed an issue with OPT and STATORS. When I switched to STATUS = 'REPLACE', recently, it broke a feature of OPT and STATORS. Moreover, both programs were designed to store all of the example
files. This feature is now working again
04/11/24 Update 1:
- Renamed some of the XYZ points files, to make it clear that they are optional
04/10/24 Update 2:
- Changed some internal variable names, to make them more clear
- Improved the XYZ dimension checks output file, to facilitate plotting
- Added a new plot, to the XYZ folder, for the dimension checks
- Renamed a plot in the XYZ folder
- Updated the user manual, to account for today's changes
04/10/24 Update 1:
- Completely automated the checking of critical dimensions. This saves a huge amount of CAD work. This feature only applies to XYZ
- Made a few improvements to the output of XYZ
- Added a plot to the XYZ folder
- Made a slight change to the invalid geometry check for BETANZ. The way I had it coded conflicted with the default options that I use for partially twisted blades. This change applies to all
codes
04/09/24:
- Made a few more changes to XYZ output files. This was to make it easier for new users to identify critical dimensions, reference dimensions, and reference info
- Added a missing boundary condition for BETAPHIZ
- Removed BETAPHIZ from codes that don't need that variable
04/08/24 Update 2:
- Updated more of the XYZ output file names
04/08/24 Update 1:
- Removed a feature from XYZ. The feature let you plot the blades from the axis of rotation or the hub end point. Now, the code always plots the blades from the axis of rotation. This is how it
originally functioned. Removing this feature makes it easier to create CAD models (which is the purpose of XYZ)
- Made numerous changes to XYZ output files and plots. These changes were made to make it easier to create and check CAD models. Moreover, there was a lot of debugging information output. It
was no longer needed. By removing unnecessary information, it's easier to see what's important
- Added a new output file to XYZ. The file makes it much easier to orient the airfoils along the blade. This saves a lot of time in CAD
- Updated the source code notes
- Updated the user manual
04/07/24:
- It looks like I did some code refactoring, a long time ago, that broke the constant speed functionality. This is fixed now. I had replaced all ATAN function calls with ATAN2. However, I
failed to notice that one of the calls had a negative sign attached. So the original code was -ATAN and I had replaced it with ATAN2. I should have replaced it with -ATAN2
- Switched from STATUS = 'UNKOWN' to STATUS = 'REPLACE'. This isn't a Fortran 77 feature, however, it provides useful functionality. Moreover, with STATUS = 'UNKNOWN' you could end up with old
files, when a run fails. So you could get confused and think the old results are current. This won't happen with STATUS = 'REPLACE'
04/04/24 Update 2:
- Made some changes to ANALYSIS, ANALYSIS_MESH_TEST_TWO, OPT, and STATORS. These were brought on by the changes from earlier today. I removed all *.xyz files from the OPT and STATORS folders. I
renamed many of the *.xyz files in the ANALYSIS and ANALYSIS_MESH_TEST_TWO folders, to indicate that they are for debugging. I changed some of the *.xyz files to *.dat files, in the ANALYSIS and
ANALYSIS_MESH_TEST_TWO folders. The reason for all of these changes is I didn't want to create *.csv and *.asc files, in these instances. It isn't warranted and would balloon the amount of files
in the folders. The only time *.csv or *.asc files are needed is for when any given CAD program can't import *.xyz files. The *.xyz files, created by PROP_DESIGN_XYZ, are the only critical *.xyz
files. They are needed to create the propeller geometry in CAD. All other *.xyz files are for debugging purposes. *.dat files are for Gnuplot and formatted to make it easy for humans to view
them. All *.xyz, *.csv, and *.asc files are formatted to satisfy various CAD programs
- Some of the formatting changes, from earlier today, got applied to places they shouldn't have. This happened by accident, because I used search and replace. I just noticed the issue and
corrected it. The accidental formatting changes didn't cause any issues. However, they weren't what I intended
04/04/24 Update 1:
- Updated the formatting for all *.xyz files. This was done to eliminate issues with certain CAD programs
- Added *.asc files to PROP_DESIGN_XYZ. This was to allow FreeCAD to import the PROP_DESIGN point files. The *.asc files are exactly the same as the *.xyz files. The only difference is the file
extension
- Did some code refactoring on PROP_DESIGN_XYZ. This was done to make it a little easier to add new file formats. I also improved some of the PROP_DESIGN_XYZ source code notes
- Updated the user manual, to reflect today's changes
- Recently, I activated text wrapping, in all 'Command Prompt' and 'Intel Fortran' windows. This allowed you to more easily see long compiler strings. Unfortunately, it also messes up the
screen output for certain PROP_DESIGN codes. Thus, I deactivated text wrapping
03/29/24 Update 2:
- Updated the Fortran benchmark download. Made some minor improvements to the results spreadsheet. Re-ran some of the ifx tests
03/29/24 Update 1:
- All 'Command Prompt' and 'Intel Fortran' windows are now set to wrap text
- Added an additional compiler option to all c.bat files
- Recompiled all *.exe files
- Updated the Fortran benchmark download. Added statistical analysis for all test cases. This was done in a spreadsheet, using output from the benchmarking program. Updated the output of the
benchmarking program, to make it easy to do statistical analysis. Added compiler options for ifort and ifx. These were recommended by an Intel employee. They helped to improve the speed of ifx
generated code. It's still a bit slower than ifort generated code. However, they did bring the two compilers closer together
03/28/24:
- Updated the Fortran benchmark download. Added a test case for the ifx compiler. There are now equivalent tests for the ifort and ifx compilers
03/27/24:
- Updated the Fortran benchmark download. Updated the 'Auto-Parallelization Notes.txt' file, so that it matches the benchmarking program's line numbers. It was originally referencing MAPS line
numbers. I also fixed another typo in the results spreadsheet
03/26/24 Update 3:
- Updated the Fortran benchmark download. Added an additional test case for the ifort and ifx compilers
03/26/24 Update 2:
- Updated the Fortran benchmark download. I thought of a better way to calculate total cpu runtime, for the benchmarking program. I introduced this output yesterday. I also fixed a typo in the
results spreadsheet
03/26/24 Update 1:
- Updated the Fortran benchmark download. Added the CPU model, that I used for testing, to the results spreadsheet. Re-ran some of the Intel Fortran compiler tests. Improved the results
spreadsheet, so that it automatically formats certain cells (based on their values). Improved the results spreadsheet, so that issues with the Intel Fortran compiler are easier to see
03/25/24 Update 2:
- Updated the Fortran benchmark download. I added more test cases for the ifx compiler, since there is a regression showing up with the ifort compiler. This gives a little more insight into the
issue that I found. Moreover, it appears that ifort has a regression with /O2 level optimizations. Another interesting thing is unoptimized ifort and ifx code outperforms fully optimized gfortran
and flang code. Lastly, unoptimized ifort and ifx code performs about the same
03/25/24 Update 1:
- Updated the Fortran benchmark download. Updated the compiler comparison, to include the latest version of flang. There was no significant change in performance. Added the compiler version
numbers, that were tested, to the spreadsheet. Added an additional ifx compiler test. Added total cpu runtime, in minutes, to the output of the Fortran test code
03/18/24 Update 2:
- I did more compiler testing and I don't see any harm in implementing the change mentioned earlier today. Therefore, I went ahead and did so. Moreover, PROP_DESIGN no longer uses
auto-vectorization and fuse multiply add (fma). Removing fma should greatly increase the amount of x86 processors that the codes can run on. This was always my highest priority. It simply never
occurred to me that I introduced that limitation, until today. The performance difference for both of these features is too small for me to accurately capture. As always, you can get a little
more performance, if you tune the c.bat files for your specific processor and recompile the codes
- Recompiled all *.exe files
- Updated the Fortran benchmark download. Added more test cases for the Intel Fortran compiler. Even with the added averaging, the run-to-run variability is still larger than some of the
compiler option affects. Increasing the averaging should help, however, it would take way too long to run all the tests. So, I don't want to do that. Also, there comes a point where there will
always be an issue, because the OS interrupts things as well. Auto-vectorization and fma seem to be within the run-to-run variability. I also updated the results spreadsheet
03/18/24 Update 1:
- I updated all of the c.bat files and recompiled all of the codes. They may run slightly faster now. While working on this, it occurred to me that not all x86 processors have fused multiply
add (fma) functionality. I currently have that turned on. It only provides a slight boost in performance. However, it will exclude a fair amount of processors. In the future, I may turn off fma
functionality. If you find that you can't run the codes, this could be the reason why. To fix the problem, you would just delete the /Qfma option from all of the c.bat files and recompile the
codes. This would require you to have Intel Fortran installed
- Updated the Fortran benchmark download. Added a slightly modified version of PROP_DESIGN_MAPS, to deal with run-to-run variability. The new program is called PROP_DESIGN_MAPS_BENCHMARK. It
runs PROP_DESIGN_MAPS five times in a row and reports the average runtime (in seconds). Updated the batch files. I also updated the results spreadsheet. It now includes the results from
PROP_DESIGN_MAPS_BENCHMARK. Updated the README file
- Based on what I saw today, I made a slight change to the default compiler options used in all c.bat files. The change should cause a slight speedup
03/17/24:
- Very minor updates to some of the documentation
- Updated the Fortran benchmark download. Re-ran all benchmarks. This was to compare with the latest version of flang. Several compiler options, that worked with the previous version of flang,
no longer work. They were removed from the batch files. Moreover, -mconsole -mthreads -static were removed. -static is the most important of these. Without, -static I couldn't distribute the
codes. -static often gets broken for gcc and flang. It will most likely work again, at a later date. There was no significant change in compiler performance. This is what I usually observe. As
always, Intel Fortran is the best compiler
02/24/24:
- Updated the Fortran benchmark download. Minor improvements to the documentation
01/22/24:
- Updated the Fortran benchmark download. Fixed a display glitch with one of the plots in the results spreadsheet
01/09/24 Update 2:
- Added a new PROP_DESIGN logo to the user manual and overview documents
- Updated the other LibreOffice Writer documents, in the documentation folder, so they all have the same page style now
- Updated the Fortran benchmark download. Updated the 'README' LibreOffice Writer document, so that it has the same page style as the other PROP_DESIGN LibreOffice Writer documents
01/09/24 Update 1:
- Updated the Fortran benchmark download. Updated the results spreadsheet, since the flang compiler was updated. No significant differences were observed. Fixed a small bug. I had renamed all
of the batch files, awhile ago. However, one of them didn't get the intended update. This is fixed now. Added auto-parallelization notes
01/05/24:
- Updated the Fortran benchmark download. I removed PROP_DESIGN_MAPS from this download. This makes the download smaller and reduces redundancy. The download contains all the information and
files needed, to run Fortran compiler tests for yourself. You simply copy the additional batch files to the PROP_DESIGN 'MAPS' folder. Reorganized the information in this download. Updated the
README file. Provided *.pdf files, in case you don't have LibreOffice installed
01/01/24 (Happy New Year):
- Tried to improve the 'PROP_DESIGN Geometry' notes page. Previously, when you zoomed in, the pictures were blurry. I was able to fix that problem. However, Mathcad is really bad at dealing
with pictures. Now, the pictures are not readable at the default zoom setting. So I can't really win. I think it's better now though. Being able to zoom in is helpful. If you find that an image
isn't viewable, try changing the zoom percentage
- Fixed an error on the 'Flow Angles' picture. There was an angle labeled 'theta' that should have been labeled 'theta1'. The sketch is in the plane that the airfoil operates in. Which is the
NZ plane. I made that clear now. Angle theta is in the PHIZ plane. So it doesn't apply to this particular sketch
- Reorganized the 'Documentation' folder. Now, there are subfolders, whenever pictures are present
12/28/23:
- Minor improvements to the 'Airfoil Interaction Study' documentation
12/24/23:
- Very minor updates to the documentation
12/12/23 Update 2:
- Updated the Fortran benchmark download. There was a batch file entitled 'i6b.bat' that I used as a double check. However, I hadn't documented it. This is fixed now
12/12/23 Update 1:
- Re-release of the 'Fortran Compiler Tests' download. I haven't had it posted for many years. This is provided as an optional download, located on the 'Fortran Benchmarks' page