New Custom Feature: HAVF Profiles - Standard Airfoil Profiles

IgnacioMartos

We are releasing an exciting new Custom Feature!

Introducing HAVF Profiles, built in collaboration with Austin Holbrook and Greg Brown. This feature comes loaded with an extensive library of airfoil profiles, guaranteeing continuity at the leading edge and providing control over the core variables of the profile, such as chord length or angle of incidence.

We hope this feature will enhance your toolset when creating airfoils, not only with the preconfigured library of vectors but also with the tools to create custom libraries and vector profiles. Our user testing found greater surface quality and faster development times. We think the feature is robust, but let us know your thoughts in the comments.

You can find the custom feature here: https://cad.onshape.com/documents/33795c7f9b39612da14ee99a/v/5f0353863c39e4e7468cf450/e/7d0549e4402995ffee27b9c5

This project stemmed from a collaboration with RCTestFlight, as Daniel and Austin collaborate using Onshape. Find their propeller design competition here: https://youtu.be/oTpa0WVHspA

The feature will construct a profile using two Bezier splines, with guaranteed surface continuity at the leading edge. The custom feature comes with a library of profiles, but you can also create a custom profile using a vector approximation of the airfoils in this format:

1.00000000 0.00060380 0.79245558 0.01982307 0.20893634 0.09200306 0.28069787 0.01922811 0.31444604 0.07222109 0.00000000 0.05201070 0.00000000 0.00000000 0.00000000 -0.03961872 0.61853657 0.02424800 0.14054043 -0.03827816 0.56753783 0.00663705 0.93859584 -0.00533977 1.00000000 -0.00060620

Included in the custom feature is a segment of the Holbrook Aerospace Profile library; you can find an expanded library of airfoils on the Holbrook Aerospace website. [https://holbrookaerospace.com/product/album-2/]. If you wish to implement more vectors into your library, we have added the database Feature Studio tab, havfDatabaseExample.fs. As the airfoil profiles we included in the feature are proprietary the core library is hidden, you can add a second database or switch to your own set of vector profiles.

We are eager to see what you build with the new tool. Please add your comments so we can consider any future enhancements.

This is not an official Onshape feature, and maintenance is not guaranteed.

S1mon

This is exciting to see.

A few thoughts:

1. A boundary surface might be better than loft in many cases since it will likely result in a much more simple surface - especially if the two profiles are the same or at least similar in the number and placement of CVs.
2. The approximation of the profiles into single span Bézier curves gets rid of some of the horrible curvature issues that other airfoil generators have had using fitspline (degree-3 multispan), but the current technique is still producing CV layouts that are not ideal for surfacing work. They may be ok for just a wing itself, but any transitions or tips might end up being convoluted because the control polygons are zig-zagging or looping.

Here's a boundary surface through two AG03 profiles:

P2, P3, and P4 of the curves are looping around, which is not ideal. See these "Golden Rules" from Alias, which apply to any NURBs surfacing:

https://help.autodesk.com/view/ALIAS/2024/ENU/?guid=GUID-A23E9E8C-6D6B-41AD-A0AB-3E98183FBC2E

I wonder if there is a better approach to fitting a curve to the coordinate tables? If the goal is also to have any given profile blend smoothly into another, perhaps it would be better to space the CVs out in a consistent pattern along the chord length (X), and fit their Y positions so that the curves result in a good least squares fit to the coordinates? This would greatly improve the parameterization of the curves.

MichaelPascoe

Very cool! There seem to be a consistent number of users always asking for this kind of thing.

martin_kopplow

S1mon said:

...

I wonder if there is a better approach to fitting a curve to the coordinate tables? If the goal is also to have any given profile blend smoothly into another, perhaps it would be better to space the CVs out in a consistent pattern along the chord length (X), and fit their Y positions so that the curves result in a good least squares fit to the coordinates? This would greatly improve the parameterization of the curves.

The tradition of spacing the x coordinates depending on the airfoil surface curvature and pitch relative to the chord at the location comes from the approximation made for classic airfoil software and makes sense there. Especially in the LE area it probably still does. Since there is a minimum control point density required for accuracy in the critical zones, equal spacing might result in much more control points in the less curved areas.

S1mon

@martin_kopplow
Note that I said “consistent” spacing, not equal spacing. I don’t know what the right answer is, but more density at the leading edge would make sense. There might even be a nice logarithmic spacing which is the most efficient. The first two CVs are going to need to be at the same X=0, but after that, the space between them will want to get gradually larger.

Many of the approximations I’ve seen end up with weird increased curvature at the trailing edge. I only know so much about airfoil design, but I assume that is an artifact, not the intended result. The NACA shapes have continuous mathematical definitions. I don’t know how to convert that directly to a Bézier, but at least the equations can be used to check the results.

https://en.wikipedia.org/wiki/NACA_airfoil

martin_kopplow

@S1mon There are in fact airfols that have an increase in curvature towards the trailing edge, mostly due to the camber. Not as much as at the L.E., but definitely stronger than in the center section. A "consistent" spacing might be appealing, but it may have it's limitations, if the overall number of coordinates is to be limited for reasons of computing performance and continuity. A reproducible dynamic spacing, based on some formula that takes shape and curvature into account, might be possible, but then, different airfoils might blend awkwardly, if not otherwise constrained. Also, upper and lower profile are usually very different, each requiring their own spacing. Maybe some kind of landmark points, which are not nessecarily a member of the coordinate points, but mathematically identified on the surface, could help to identify corresponding locations on different airfoils and could later be used as connection points later. It is difficult.

IgnacioMartos

@S1mon, anything to do with the vector approximation and the coordinates used falls under Austin's algorithm, he is having some issues posting in the forum, so here is his answer to your question: 

"I think the increased thickness factor of the AG03 foil on the far side of the loft is making most of the inconsistency. Your idea about spacing has some good points, especially for simpler foils like this. But I could solve more complex airfoils without crossing some X control points. For the sake of a low entropy library, I made all foils in this library have the same number of control points. I chose the current amount of inputs after a couple of weeks of trying to make them at different levels of detail, finding that this resolution was the minimum that I could make accurate fits for all airfoils with. I do think every foil has an ideal number of control points. It would be cool to see how that plays out in another version of the library, especially with spaced X inputs. I have a couple of ideas on how you could do that while still prioritizing accuracy."

S1mon

@IgnacioMartos

The AG03 airfoil definitely has a nasty loop of CVs, but in very limited review of a few other profiles, zig-zags seemed to be common as well.

Technically, a single span Bézier is infinitely mathematically continuous, but that doesn't mean that it's always a smooth, fair curve. A degree-3 Bézier can create a cusp which is C^infinity, but only G^0 at the cusp. Onshape won't let you create cusps or self-intersecting loops, but mathematically, these degenerate cases exist. 


With the degree of curves that you're creating, you won't see cusps or loops in the curve from a loop of CVs like you have, but you will get uneven parameterization. Notice how the isoparametric curves are bunched up where the CVs are looping.



When you're using the same curve at both end of surface, the parameterization doesn't matter so much, but watch what happens when you use different curves at the tip (see below). The isoparametric curves (which are straight lines in this case) fan out-or-in very differently depending on the parameterization of the tip curve. In this case, I'm using a boundary surface for the cleanest surface. If you use a loft instead of boundary it might do a better job of evening out the parameterization, but overall boundary would be a much better choice for downstream surfacing work.

austin_holbrook246

Here are the pictures I wanted to post as well. Let's see if I can comment yet!

austin_holbrook246

repeat post removed

austin_holbrook246

repeat post removed

austin_holbrook246

Ans1: Yes I have noticed that boundary surfaces do work better. But I've always relied on them more-so than lofts, so I may be biased. Or maybe my preference is explained by this issue you are raising? Also I have more history with SW. I am still learning OS and having fun in the process.

Ans2): If you wanted to space out the X coordinates as evenly as possible, there are many ways that you could add that to the fitting function. There are often a few solution to an airfoil, especially for the more simple airfoils like the clarkY, n2412, etc (or ag03 in this case). I heavily disfavored reducing the control points count, because it reduced accuracy even with the simpler airfoils, and it added entropy to the library to have fewer coordinates for some airfoils, which I did not want. (Mostly for purposes related to the optimization utility of the library). I guess the question then is, if you add a spacing weight into the mix, how much do you prefer spacing to accuracy? I think the two best options would be to either A) Use the current library, and make X boundary conditions for all the X variables, each within their own range, and try to find better solution with those additional boundary conditions Add a spacing weight to the fitness function, and remove it near the end of a fitting optimization, pushing your solutions towards the most evenly spaced during almost the entire fitting optimization, until the last second when you prioritize accuracy.

That's just what I am thinking off the top of my head. Of course there are more options. But, what I think should be noted, is that some airfoils are just weird. There is no requirement for smoothness in the original coordinate database. Sometimes airfoils are just harder to find solutions to than others. Some airfoils that naturally have a lot of curvature are hard to fit. Some airfoils with low amount of coordinates can be hard to fit accurately to their original analog shape. Sometimes an airfoil coordinate file will appear normal, and have a very very very small disjoint in Y or X. With a library as large as 1600 airfoils, you will see all sorts of cases come up. Sometimes I think people underestimate how long some of these foils have been around, and how much of a game of telephone has been going on over the decades. So already, there is lots being lost, or redone differently, making all airfoils into splines. In some sense we are continuing the game of telephone here, but also making a new standard that won't require as much telephone in the future (hopefully). Once an airfoil is defined as a spline there is no more questions where the line lies, as there is between coordinates.

But, if there were a need, I do think there would be utility in making more solutions. But I think that might be an easy way to wade into deep waters. If you find a solution that is spaced more evenly, but is 10% less accurate, how do you decide which solution to keep? It's a big question. But the likely answer is that there is always a better solution. Perhaps when that becomes more apparent I will release an updated book of HAVF airfoil solutions. But! do not underestimate the solve time!!! I am not the best coder, but it did take me a while to run the compute for this library.

I think the best solution for now is the custom inputs. Having an airfoil be so adjustable and durable, means you can spend time making an airfoil. You are no longer adjusting a single profile on a single version of a single part. You can save the HAVF vector and use it forever. So there is much more incentive to make the adjustments you want. I will make more instructions about how to do that soon.

I'd be lying if I don't dream of having this all be simpler to do. Making a qualify hub interface or wing transitions is always a big job. Especially when you are about to go to tooling. If you'd think you get rid of most of the manual surfacing work by combing the existing library a certain way, that would certainly save me even more time. In your professional opinion, do you think this type of solution combing could decrease the surface modeling time by 90%? Do you think additional control points would need to be added to ensure no overlapping X control points for higher curvature foils? If more time could be saved, and you can get higher quality surfaces, I think there is a huge incentive to go back and take a second look. But the pessimist in my thinks that there is going to always be a large amount of manual surface work to do.

I think I have said about all I can. But I may actually not be the best person to ask. I have a lot of experience making the format, and dealing with the issues it creates, but I have been using it for a while now, and I may be used to the problems it causes. On last thing I would say, is that the HAVF format give a lot of power to the input. It's just raw splines and not safety rails. So if there is a bad input, you can totally make a bad airfoil, and cause yourself lot's of problems. I tried to exclude that as much as possible from the library in the book of course.

austin_holbrook246

repeat post removed

austin_holbrook246

There is no requirement for the current format to have overlapping X values, and not all current solutions do. A good solution for now, is to make your own custom inputs. When you make your own inputs, you can create whatever kind of special conditions you would like to impose upon them, and still use the existing feature. The book itself will be a good guide in terms of control point position, maximum and average error, and thickness and camber values. (https://holbrookaerospace.com/product/album-2/)

Of the airfoils that have overlapping X values, I would say a very small percentage of them have the discontinuous curvature. I have only found 2 in the last 9 or so months that I published. The library is not perfect, and neither is the format, but its very functional and useful. Like I have said before, I definitely have an interest in making more libraries, and this is undoubtedly utility in that pursuit, but I just don't have time right now.

austin_holbrook246

As far as "smoothness" I will be transparent. There was no weight in my fitting algorithm for smoothness. It was a least squared error fit. Every time I tried to limit the curvature, or the derivative of curvature, I just end up with a large amount of error in the precision. The dataset being fit is coordinate based, and there are many airfoil coordinate sets that have been standard for decades that aren't easily fit with a very smooth line for many reasons, either the coordinates were edited individually, or the initial measurements of an analog foil each had a small amount of error in them. Either way, its start of kind to be a grey line. There is no requirement actually for an airfoil to be smooth. Of course smoothness usually helps in the general appearance. But, to the degree we are talking about here, ome slight changes in the surfaces, (increases or decreases in curvature) could actually be advantageous aerodynamically. Also, when enforcing find curves, there is always going to be some balancing act with accuracy. You can't enforce smoothness without impacting accuracy.

S1mon

I suspect there's a lot of noise in the coordinate databases. Your thoughts on a game of telephone are very likely correct. Even if they are true to some clean mathematical definition, fitting exactly to those numbers will produce wobbly surfaces.

I've seen this before in much more known contexts. Even if the numbers are correct to some number of decimal places to some perfect surface, they are rounded or truncated and fitting exactly to sampled points often produces bad surfaces.

For Example: Apple publishes accessory design guidelines which include 2D drawings but not 3D STEP files. None of the "rounds" on their products are arcs (at least anything larger than a couple mm), they're all splines with G^3 continuity to adjacent flat surfaces. They dimension the shapes on the 2D drawings with X/Y inspection coordinates. Here's a detail from one of the watches. Note that the coordinates are all shown with 2 decimal places, and I'm assuming that they come directly off the NX database which is used to produce these parts. If you try to fit a spline (especially a degree-3 mulitspan) through these numbers exactly, you will get something wobbly. Perhaps if they gave us 3 or 4 decimal places it would be better, but ultimately there is some error band around these numbers. In the case of this Apple drawing, there's a ~ +/-0.005 error band around a lot these numbers due to only two decimal places being shown.

I'm not an aeronautical engineer, but I've spent a lot of time trying to reconstruct really good surfaces from sampled data. In this case, if I were trying to develop a good algorithm, I would play with how to space out the CVs, the acceptable error band, and the number of CVs. In a perfect world, you'd also have some sort of "fairness" metric that you're optimizing for as well. Tons of research papers have been written on this topic, and there are a lot of different approaches.

I see a lot of people trying to work with airfoils or doing boat hulls using some level of incomplete information. Even when you have what seems like really good info, it can be really challenging without some sort of smoothing/fitting going on.

GregBrown

It’s great to see the discussion on this new Custom feature! Thanks to Austin for being so open and willing to chat. For those that want to experiment, there is a custom data entry option (as Austin pointed out) so I encourage people to look at the references in the code to the format. The cool thing is that if you use this method, then all of the other tools in the feature (orientation, TE thickness, thickness scaling etc) will work just fine. Let me know how things work out!!

S1mon

austin_holbrook246 said:

There is no requirement for the current format to have overlapping X values, and not all current solutions do. A good solution for now, is to make your own custom inputs. When you make your own inputs, you can create whatever kind of special conditions you would like to impose upon them, and still use the existing feature. The book itself will be a good guide in terms of control point position, maximum and average error, and thickness and camber values. (https://holbrookaerospace.com/product/album-2/)

Of the airfoils that have overlapping X values, I would say a very small percentage of them have the discontinuous curvature. I have only found 2 in the last 9 or so months that I published. The library is not perfect, and neither is the format, but its very functional and useful. Like I have said before, I definitely have an interest in making more libraries, and this is undoubtedly utility in that pursuit, but I just don't have time right now.

Very interesting. I haven't looked through more than a sampling of the airfoils, but it seems like they have all been converted to degree 6 Béziers. Of the 4 sample airfoils on this page, only one of them (the clarky) has CVs which follow common guidelines for high quality surfacing. The others have zig-zagging CVs.

It seems like 7 or possibly a little higher would be better. When I've tried matching sampled curves with a curve that is too low of a degree, if I can get it to resolve, weird CV distribution often results. The minute I increase the degree to something that can manage the underlying constraints, the CV placement can be much more rational.

Let's assume you have a perfect mathematical definition of the airfoil, but you need to convert it to single span Béziers. In order to match an arbitrary perfect curve with G3 continuity at each end, you need at least a degree 7 curve (unless the perfect curve happens to be something more simple). If the middle of the airfoil has any complexity to it, you might need more than degree 7, or consider multi-span with lower degree (e.g. 5). One could argue that you don't need G3, but given the importance of the leading and trailing edges, I would assume that G3 matching would be a good idea.

austin_holbrook246

Yes, they are 6 deg curves. But just to comment back on the math section. I am using 9 sig figs, and most of the coordinate outputs from the spline are irrational numbers. 9 sig figs is on the high end for airfoils. Some raw coordinate foils that I tried to fit have less than that, and that can cause some problems too. So, even if the original airfoil was made with "perfect math", and had ideal smoothness, the process of making it a coordinate file, and then trying to make it a spline based airfoil is never going to be perfect. The second anything is made into coordinates, it's destructive to it.

Increasing the spline count is one solution. But so is decreasing down to a 3 deg spline. With two control points at the leading edge, and one on the trailing edge, and only one floating in the middle, it's almost impossible not to make a very smooth surface. You'd kind of be sacrificing  surface quality at the leading edge. But, for a much lower amount of input, you'd actually solve a lot of the points you are concerned about.

I have a library of 4 deg spline fitted solutions like that. They are easier to solve airfoil fits for as well; not as many variables to adjust. But I probably won't publish them because they aren't accurate enough. I have a smaller 5 deg. library, but I didn't complete it after realizing that it too didn't have enough flexibility/accuracy. The reason I stopped at 6 is because it leaves the airfoil with 20 variables. Each degree increases variable count by 4. Some of the most modern parametric airfoil languages, almost have about 20 variables, so increasing beyond that starts to weight down HAVF. But there is no reason HAVF can't be done in other deg of splines. It already has been, and in my book I talk about that as well. Maybe it would be possible in the future to have the feature accept custom inputs of any degree. I left the placeholder dummy variables in the format mostly for my own human sanity (the un-needed 1's and 0's). But they can also serve as divisors for the coordinates. That way, you wouldn't even need to have equal deg splines on top and bottom. I think a small group of users would probably use that.

If it only a surface modeling problem, and the accuracy is already there, then I believe there are already some good spline fitting features in Onshape. You could simply place points on the profile, and fit a smoothing spline to it if you found anything you wanted to smooth over.

austin_holbrook246

Here is an example of using the feature, both with the book, and with the stock airfoils in the feature. You can really lean on the feature and use its ability to implicitly define a chord using a planform to get a lot done, and done accurately.

https://www.youtube.com/watch?v=XH7auwT6p4Y

S1mon

@austin_holbrook246

That's a nice demo. The ease of the airfoils updating parametrically is certainly be a game changer for this kind of work.

It will be great when @GregBrown releases his approximate curve from two projections. I couldn't quite tell, but it seemed like you had some extra work to do in order to get the trailing edges to loft cleanly. 

austin_holbrook246

Yes, I had trouble with the trailing edge. Usually I would be happy with one guideline on the leading edge. In some cases, no guidelines at all. But, in this case the point was to have a consistent gap between the wings. So I needed both the leading and trailing edge to be exactly where I wanted at every point along the span. This stressed the loft feature I was using, beyond my usual use of 1 guideline. I think it would work in SW because I expected it to here. But, the trailing edge didn't like the rear guideline in the center of the thin trailing edge surface. I tried splitting the line defining the trailing edge surface into two lines. Usually in the current version of the feature, if the TE thickness is real, its one line. That didn't work as well as I thought, so I found is was easier to grab the upper and lower points in the profile of the trailing edge using two separate guidelines. So I had to form new guidelines. I just used the 3D fit spline tool to pick up a couple points from planes in between the wing root and tip. It was a little more work, but it updated really well every time I adjusted the extruded surfaces that controlled the major wing shape. I don't know if this use case is common enough to add a split trailing edge surface to the main feature. For some reason, for the short period I tried that, it didn't work well. But maybe I should have used a boundary surface from the start. I am still new-ish to Onshape and I need to practice more, because I am sure there is an easy way I could use the original guide line. I am always happy finding a simpler strategy and not over complicating the feature.

marc_frank

Hi

I saw the livestream "Design, Prototype, Fly: Behind the Scenes of Propeller Engineering" today.

One aspect I really enjoyed hearing was the open source and freely available aproach.

So here is my take on it. Over a year ago i developed the BezierAirfoilDesigner which is free and open source available on GitHub. It has allowed many people to do the same and more what Austin tries to do with the HAVF format, except there is no need to purchase a book. The latest version of the app has 201 downloads and 477 downloads over all versions.

https://github.com/marc-frank/BezierAirfoilDesigner

Using it I created this bezier curve fit of the AG03. The control point distribution is very clean.

Here are the control points in the .bez.dat format that has been used by this software:

AG03
1.0000000000000000 0.0006620000000000
0.5407881779306396 0.0478750578175452
0.2832687330676348 0.0659407753126509
0.1099098032037015 0.0583130212404137
0.0138200336718360 0.0385295801896016
0.0000000000000000 0.0067495733787609
0.0000000000000000 0.0000000000000000
0.0000000000000000 -0.0189113355181787
0.1558527243682143 -0.0132977046339958
0.1296095458933629 -0.0121306144620726
0.2038153136994605 -0.0126212315892537
0.5775243166434714 -0.0065806224573888
1.0000000000000000 -0.0005480000000000

This format is essentially the same as the Selig .dat airfoil format, just containing the control points of the bezier curve.

An alternative is the .bez format that allows some more flexibility:

AG03
Top Start
0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0067495733787609
0.0138200336718360 0.0385295801896016
0.1099098032037015 0.0583130212404137
0.2832687330676348 0.0659407753126509
0.5407881779306396 0.0478750578175452
1.0000000000000000 0.0006620000000000
Top End
Bottom Start
0.0000000000000000 0.0000000000000000
0.0000000000000000 -0.0189113355181787
0.1558527243682143 -0.0132977046339958
0.1296095458933629 -0.0121306144620726
0.2038153136994605 -0.0126212315892537
0.5775243166434714 -0.0065806224573888
1.0000000000000000 -0.0005480000000000
Bottom End

These file formats have a simple name, don't draw attention to a paticular person, a tool has been written to import these files into Autodesk Fusion and have also been used as a data interchange format with other design software, the Airfoil Editor:

https://github.com/jxjo/PlanformCreator2/tree/main/AirfoilEditor_subtree

You can read more on this software in multiple different forums:

https://www.rc-network.de/threads/neue-app-bezierairfoildesigner.11962964/

https://www.rcgroups.com/forums/showthread.php?4390127-New-App-BezierAirfoilDesigner

https://forum.alofthobbies.com/index.php?threads/new-app-bezierairfoildesigner.3684/

It is planned to create another open GitHub repository to act as a free library of pre-fitted bezier airfoils where everybody can contribute. This offers continous addition of new airfoils and improvement of existing ones.

I also have about a million ideas I plan to implement in a rewrite V2 of the BezierAirfoilDesigner.

It might be useful to the Onshape team to be able to use this more open file format in addition to what has been created here.

Best Regards,

Marc Frank

austin_holbrook246

Marc, there is nothing preventing anyone from using the HAVF format.
Although I have gone over it most thoroughly in my book, I have explained it openly on many occasions.
No doubt, others have done very similar things in the past.
So I hope you would consider an option to export any coordinates made in your tool in HAVF array (.bsa) format.
That way it can be used in this Onshape feature.

I am partial to the arrays because they paste so well into code and spreadsheets.
For instance, mixing solutions is very easy in array format in a spreadsheet by just averaging values from different rows.

But there is no monopoly on airfoil features in Onshape either.
If you want to differentiate your format in some way, the code for the "HAVF Profile" is open as well.
I believe you could use most of it to create another feature with other benefits you mentioned.

I like the ability of your program to use different number of control points.
The Onshape feature does not support that yet, but it can in the future.
As I indicated in an earlier post the HAVF format supports other CP counts, and it wouldn't be to hard to use the origin in the data as a divider between the two described splines.It could be used to create airfoils with uneven control point count between the splines.

But, if you have put this much effort into it I highly recommend that you buy the book.
Especially if each solution is taking about half an hour.

As I am sure you are aware from your experiences, there are lots of solutions to each airfoil.
Especially when you increase the control point count, the number of solutions starts to increase.
When making my book, only about 5% of the solutions I found made it into my book.
I had four of my workstations working on my library for a couple of months, just working on improving the solutions with the most error, until the entire library had an average error that I was happy with. So you can imagine how having this book in addition to an open library would be helpful.
I also just use my book to browse airfoils, and the PDF makes is easy to search through airfoils of certain thicknesses and camber very easily, as there is lots of information about each airfoil on every page, not just the HAVF coordiantes.
The book also has an intro about how the format works, its rules, 3 ways to create your own splines, and strategies to use the language to start optimizing geometry.

One thing I would like to note, is that separate from the solution for the spline coordinates my book attempts to correct as much entropy as possible from the original DAT (coordinate database). About 2/3rds of the airfoils in the public libraries violated at least one of the rules I set up, detailing what is required from the DAT file before the spline is fit to it. The AG03 is one of the more compliant airfoils based on the rules I set up. But crucially it does not have a leading edge point at 0,0 which HAVF requires. It looks as if you tool has already taken this into account, or at least the leading edge is anchored at the origin. But its these small errors that become the most annoying, especially when you are trying to mate the chord to a leading edge, or planform.

As for drawing attention to myself, I don't think I have been overly attention seeking in publishing my book.
Certainly publishing anything is an exercise in self importance, at least in some small measure.
But I have been perhaps lucky in the way that my book has been embraced by other people/youtube channels, and at Onshape.

As a business of course, my judgment has been that publishing anything in this way would be cause a net increase in clients.
And I don't feel to guilty about that strategy. I do hope it works XD.
But whether or not I am correct, morally or monetarily, I think there is plenty of room for anyone who want to publish toolscode/programs/libraries about these kinds of spline/vector based airfoils, HAVF or otherwise.

If anyone wanted to make their own HAVF foils, I published a method they could use within Onshape just before the live-stream.
So including the sample of solutions I provided in the stock feature, anyone can make their airfoils, or any existing airfoils within Onshape, meaning you should be able to do anything you want with the feature. Book or no book!
https://www.youtube.com/watch?v=3wYx2JUVkD8&lc=UgzgR1fanRrYGi46kSp4AaABAg