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 OpenVOGEL is to provide a solution on which low budget airspace engineer students can always relay. The solution is of course also available for industry, but this is not a commercial company. This project does not work the same way software companies typically do. To start with, the project is non profit. Furthermore, there is not 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?
OpenVOGEL provides three kind of simulations:
Steady state: the flow field velocity is constant and the wakes are converged to the steady state. The air loads are computed in the final step.
Free flight: the flow field is adapted according to the response of the aircraft to the air loads. The 6 DOF equations of motion are integrated over time using a predictor corrector algorithm.
Aeroelastic: the instantaneous unsteady air loads are used to predict the deformation of the flexible wings over time using modal decomposition (linear dynamics).
What kind of aerodynamic boundary conditions are included?
OpenVOGEL 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.
What kind of models does the software support?
The general philosophy in OpenVOGEL 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.
OpenVOGEL currently supports aircraft models made of three basic components: slender lifting surfaces, thick fuselages 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 OpenVOGEL 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.
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 OpenVOGEL. 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 OpenVOGEL 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 if the efforts succeed.
Are the force and pressure coefficients corrected for compressibility?
No, OpenVOGEL 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 have enough resources to build a transonic aircraft, maybe you should consider purchasing specialized software based in a more complete theory. Some professor once said to me that building an aircraft is not something for poor people, and he was not joking. With OpenVOGEL 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 OpenVOGEL 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 OpenVOGEL only work with relaxed wakes?
Our calculation core does not include 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.
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 OpenVOGEL?
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.