program info

General questions

Take some time to read these common questions, they will help you understand our software tools.

What is the project goal?

The main goal of VGL is to provide a solution on which airspace engineering students can always relay. The solution is of course also available for industry, but this is not a commercial product and the project does not work the same way software companies typically do. To start with, the project is non profit. Furthermore, there is no interest in competing with other solutions, but only in providing a decent quality standard within the limitations of the implemented methods and available resources. (which are very scarce). The current tool provided by the project is more or less feature complete and the long term vision is now focused on stability.

The existence of the project in the future is related to the availability of similar solutions. Whenever other solution offers a higher computation capability under the same terms, our mission will be accomplished. The calculation power of standard computers is increasing and full CFD might become the norm in a few decades, which might likely leave traditional panel codes behind in the museum forever. In the meanwhile we remain here.

What kind of simulations does the program support?

VGL provides three kind of simulations:

This you should always remember

Before you start thinking "oh this program is great, I want to buy it right now!" (which you fortunately don't need to do), there are a few things that you need to take into account and might sound disappointing. VGL is fully based in potential flow theory for the calculation of the aerodynamic loads. Be aware that although this method can be very useful to solve some real-life problems, it will miserably fail in some situations (in this and other similar programs, no matter how refined they are). Potential flow theory is for instance unable to predict flow separation and is very limited in the simulation of boundary layers (which we do not do here). As long as the flow remains attached to the surface and boundary layers are thin (in relation to the size of the body), results should be fairly good. But this is typically not the case in most of the practical problems. Very often the flow detaches from the surface or the boundary layers grow considerably, creating pressure drag that can even be unsteady (oscillating air-loads). When the software is not capable of simulating this (like our case), you should be careful. When the software can simulate this, you should be even more careful. Many times the authors of aerodynamic software manage very well to match real-model measurements in order to promote their programs, but based in my experience I warn you: there is no such thing like a magic aerodynamic software where you can throw a model and get the absolute truth in return (this I can reveal because I don't sell software). On top of the inherent limitations, the theoretical models in which software is based always let some free variables that should be tuned somehow (like for example, the extent of the convection edge in our case, or the tuning of the boundary layer in other cases).  Also remember that in practice, airplanes and other aerodynamic systems are very sensitive to small things like dust and roughness and so they can perform in a more or less wide spectrum, so there is no point in trying to judge a design by only one number. A smooth and clean wing can perform great in the lab, but what about the same wing with dust and or the leading edge full of bugs? My point is that when you design something, do not expect the things to fall on an evident line, you better treat the variables and results as an spectrum (see as example some of our validation cases, where two lines are drawn indicating the effects of more and less convection edge on the drag prediction).

What are the main information sources of the project?

The project is based on theories extracted from several academic documents. Part of the theory has been resumed on the Wikibook. If you need more details you have to examine our main sources of information:

What kind of aerodynamic boundary conditions are included?

VGL is based in a calculation core that allows the combined definition of Dirichlet and Neumann boundary conditions on quadrilateral and triangular panels. This makes possible the creation of a combined model were the fuselages are treated as thick bodies and the wings are represented by slender surfaces, resulting in a fast and accurate prediction of the main aerodynamic forces and moments. The software automatically sets the local boundary condition type according to the type of surface.

Treating wings as slender surfaces allows a fairly good prediction of the induced drag by the traditional method, while keeping a reduced number of panels. The skin drag on wings is computed using two dimensional airfoil polars, which can be obtained from an external source (XFoil or wind tunnel data, for instance) and then loaded into the program via the graphical interface.

On thick bodies, the skin drag is currently not being computed. An effort is being done to include this effect by means of an algorithm that integrates a turbulent boundary layer along the stream lines attached to the body, taking into account the outer stream velocity and pressure gradient. The method can be found in Introduction to transonic aerodynamics, by Roelof Vos and Saeed Farokhi.

What kind of models does the software support?

The general philosophy in VGL is that you specify a parametric object, and the software does the meshing and all complex calculations for you. You can modify the number of panels you want, but the structure of the mesh is automatically generated according to strict rules.

VGL currently supports aircraft models made of three basic components: slender lifting surfaces, thick fuselages (either parametric or imported in STL) and jet engine nacelles. You can additionally model wind turbines by means of the lifting surfaces if you let the airflow rotate along the turbine axis. More models will probably be added in the future as people become involved in the development.

Lifting surfaces in VGL can be quite general. They are built up from a set of adjacent quadrilateral macro panels that can be bent and twisted. Fuselages, on the other hand, are lofted surfaces generated from a set of cross sections. The program is capable of properly connecting wings to fuselages, but on the current version, anchored wigs cannot overlap in longitudinal direction (this will be possible when we bring back the unstructured fuselage meshes -which I regret to have removed-).

Have results been validated?

Yes, results of forces over lifting surfaces and closed fuselages have been validated both, numerically (using academic software based on the same method) and practically (using NACA/NASA reported data or analytic solutions). More information about validation can be found in our Wikibook.

Note that for the moment only lifting surfaces are able of providing unsteady loads, and therefore the transit and aeroelastic simulation modes are limited to pure wing models.

For the structural model, the eigen modes and eigen frequencies of the beam element assembly have also been validated (using academic data). The integrator of the dynamic motion has only been partially validated. If you are doing classic static aeroelasticity (aileron reversal and divergence) then you are safe. If you are doing flutter analysis, consider checking the results (and don't forget to provide feedback).

Is the program really suitable for aeroelasticity?

Partially. As mentioned before, the program (as it is now) is mainly suitable for classic static aeroelasticiy problems, and will provide a much better approach than the analytic 2D solutions based in airfoils. You still have to take into account that no stall is simulated, and that the structural model is linear (hence, the displacements must remain small, there is no skin buckling prediction, etc.).

In the Wikibook you will find an example of an aileron reversal curve that has been fully obtained with VGL. The way to reach this state is by setting a supercritical damping factor (so that the structure reacts as a thick pudding rather than like a spring). Subsequently, you run several simulations using a range of aileron deflections (something that needs to be done manually, since there is no automation) and you extract the converged steady state results.

There are ongoing efforts to use VGL as main tool to predict flutter speeds (post processing using other tools is still required, like for instance to make a study of the modal responses in the frequency domain). More information will be provided in the future.

Are the force and pressure coefficients corrected for compressibility?

No, VGL makes no correction for compressibility effects because it is way too complex for 3D models and it exceeds the boundaries of our goal. If you are seriously dealing with transonic aircraft, maybe you should consider purchasing specialized software based in a more sophisticated theory. With VGL we bring some relief, but it is just unreal to expect we will someday cover it all.

In practice, the celebrated 2D formulas are good enough for low subsonic flow (which is the case for light and general aviation), but nobody guarantees they will always apply. To bring some hope, the correction I deed for the NACA RM-A51G31 validation case using the simple Prandtl-Glauert formula seems to yield very good results, and this was for a low aspect ratio wing where the airflow is quite 3D.

In any case, to avoid misunderstandings we prefer letting you do the dirty job the way you think is better.

Why does VGL only work with flat lifting surfaces?

Our calculation core does not include the full 3D model for the lifting surfaces simply because they require more panels just to obtain the same degree of accuracy on the air-loads. 

Although it might look nicer and more sophisticated, the full 3D wing model will not give an accurate estimation of the flow-field around the leading edge (an extremely dense mesh would be required for that). Integrating the pressure coefficient on the surface will therefore not lead to an accurate induced drag (this has been demonstrated in papers). Therefore, since the lift is very accurately predicted using flat panels (see validation cases in our Wikibooks documents), there is no benefit whatsoever on using twice the number of panels for the same result.

Why does VGL only work with relaxed wakes?

Our calculation core does not include pure fixed wakes because they are not well suited to analyze the interaction between surfaces (think, for instance, about the down-wash at the empennage in a classic configuration). Prefixing the wakes in the direction of the stream allows a much faster calculation (in only one step), however, the resulting wakes will most probably intersect other bodies or will not be in the correct position, making the prediction of air-loads less accurate.

On top of this, in order to reduce maintenance and bugs, we try to keep our source code as simple and clean as possible. This translates in that we try to avoid overloading it with too many different algorithms.

What the software does provide regarding this, is the option to extend the wakes in the stream direction after the wakes are trimmed during the steady state analysis.

Why is it all written in .NET?

While most engineering projects are written in C++, we have chosen for .NET due to its higher level of abstraction (from the machine). While this sacrifices some performance, it makes the development much easier. Otherwise, the consumed time would be so large that we would probably not be an open source project. For most of our native classes we have chosen for VB.NET over C# simply because the resulting code is more legible. Furthermore, both languages produce almost the same compiled code, so there is no difference in performance.

Can I use Intel MKL in VGL?

Yes, since 2020 we are able of interfacing Intel MKL for the LU decomposition of our large aerodynamic influence matrix. However, you need to do some minimal work to make it run. The instructions are detailed in the Wikibook. Strictly speaking, you can only use MKL from our Console project. However our remote interoperability lets you launch a calculation in the Console from Tucan itself, so that is not a real restriction.