Hi all,
A bit of news on the on-going development. For those of you following the code updates, you will have noticed that I've done some deep code cleaning and documentation lately.
The goal is to make this code more modular, understandable and flexible for modifications and addition of features.
The program seems to be robust enough now, so I'm releasing v6.09.06. There may be a .07 depending on the feedback and on the potential bugs that will be reported, but it won't go much further than that.
Future plans and ideas for a v6.10 or a v7
1. remove the option for independent wings; this option is here as a legacy, implemented before the plane option was proposed, but it isn't really necessary and it leads to big code complexity. So I'll remove this in the next version. I guess it will be seen as a regression by the users, but it will make the code more simple, robust, and less prone to errors.
2. remove the option for symmetry in plane analysis. True, this option saves time for the analysis of symmetrical wings, but it can't be used if a fin is defined, which is the vast majority of cases. On the other hand, it leads to big increase of complexity in the code, and is a recurring source of errors. And all in all, I tend to find that the time savings are just not worth the complexity.
3. multithreaded matrix construction and LU factorization: this shouldn't be too complex to program, either by implementing directly the algorithms, or by using opensource LAPACK and BLAS libraries. Would save significant time in plane analysis.
4. construct all arrays dynamically at run time. This is now the case for the panel and matrix arrays, but it could be useful to remove the limitations on the number of foil points, span stations and chord panels.
5. create a new binary file format to replace the terrible .wpa which has become quite unmanageable with time.
6. implement import/export of foils, bodies, NURBS, and planes to standard formats, possibly using xml; I've started to do this with the NURBSDomDoc class, but it's not my speciality and I didn't manage to complete the task. Otherwise DXF and other exchange formats could be considered.
7. A very interesting development would be the implementation of high order/curved panel methods. Most of the methods to achieve this are published work, but there are some technical difficulties not to underestimate, for instance for the integration of singular integrals on curved panels. However, since the tedious part of the work is done, i.e. the panel construction and the pre- and post-processing interfaces, this could be the next big development goal for a v7. I'll do this at some point, but not any time soon.
I'll be interested to have your suggestions and your views on the above. If somebody wishes to implement some new feature, I'll be glad to provide technical assistance if needed.
André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as curved (say high order) panel methods, I think is worth mentioning the work of Prof. Luigi Morino (at U. Boston, but available through NASA TR-Server). One can find even the source code (Fortran IV) of the initial SOUSSA (hyperboloid based) panel method.
Concerning the evaluation of singular integrals, this Morino works and also the works at SAAB-FFA related to their higher order methods (cuadratic panel).
PANAIR theory is open through the same NASA source, and a copy of A502 (Fortran 90) from PDAS (the website of Ralph Carmichael, one of the PANAIR originators).
Further, the works of Dr. John Hess in several articles, and also several reports on MCAERO (cuadratic panel)
Juanjo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another idea: implement automatic differentiation for the calculation of the stability derivatives. Right now it's done by a simple forward difference, and although the results looks fine, it would be more robust, and nicer, to do it by automatic differentiation. This is how it's done in AVL. I'm not sure that the xflr5 code in its current state allows that, but it will be worth a try at some point.
The first step anyway is to clean the code. I'm doing that right now, and it's incredible how much useless complexity has crept in over the years. I'll commit a hugely simplified v6.10 in January.
André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
one really nice thing would be to have a python api for the xfoil-class...
there is pyxfoil already, but it would be really cool to have a nice and clean c++ class...
except for qt-includes i see no obvious obstacles..
thanks for the good tool!
simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i found the function specal (7647) which might be all it needs except for the public variables (alpha, cd , cw,...)
sorry im not so much into c++, so i did not find those yet (in xfoil.h and foil.h) but i keep looking..
regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know I'm late to the party on this topic, but a bit more on what hiaselhans was suggesting. It would be good if there was a QT free library (libXflr5) which contained the models and algorithms and then have the application use this library so there is a clean separation. This would help in integrating Xflr5 functionality into other projects. I don't mind contributing some time towards this goal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In v6.10, the GUI, geometry, XFoil, LLT and Panel analysis are all managed
from distinct classes. Technically, I guess it's possible to go a step further and push those classes in separate libraries.
Still, I'm not sure how useful this would be, or how another program would use these libraries. The interfaces would required considerable documentation for the data to be supplied to the library in an acceptable way, and this is a lot of tedious work.
Let me know how you see things, and I'll see what can be done.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
A bit of news on the on-going development. For those of you following the code updates, you will have noticed that I've done some deep code cleaning and documentation lately.
The goal is to make this code more modular, understandable and flexible for modifications and addition of features.
The program seems to be robust enough now, so I'm releasing v6.09.06. There may be a .07 depending on the feedback and on the potential bugs that will be reported, but it won't go much further than that.
Future plans and ideas for a v6.10 or a v7
1. remove the option for independent wings; this option is here as a legacy, implemented before the plane option was proposed, but it isn't really necessary and it leads to big code complexity. So I'll remove this in the next version. I guess it will be seen as a regression by the users, but it will make the code more simple, robust, and less prone to errors.
2. remove the option for symmetry in plane analysis. True, this option saves time for the analysis of symmetrical wings, but it can't be used if a fin is defined, which is the vast majority of cases. On the other hand, it leads to big increase of complexity in the code, and is a recurring source of errors. And all in all, I tend to find that the time savings are just not worth the complexity.
3. multithreaded matrix construction and LU factorization: this shouldn't be too complex to program, either by implementing directly the algorithms, or by using opensource LAPACK and BLAS libraries. Would save significant time in plane analysis.
4. construct all arrays dynamically at run time. This is now the case for the panel and matrix arrays, but it could be useful to remove the limitations on the number of foil points, span stations and chord panels.
5. create a new binary file format to replace the terrible .wpa which has become quite unmanageable with time.
6. implement import/export of foils, bodies, NURBS, and planes to standard formats, possibly using xml; I've started to do this with the NURBSDomDoc class, but it's not my speciality and I didn't manage to complete the task. Otherwise DXF and other exchange formats could be considered.
7. A very interesting development would be the implementation of high order/curved panel methods. Most of the methods to achieve this are published work, but there are some technical difficulties not to underestimate, for instance for the integration of singular integrals on curved panels. However, since the tedious part of the work is done, i.e. the panel construction and the pre- and post-processing interfaces, this could be the next big development goal for a v7. I'll do this at some point, but not any time soon.
I'll be interested to have your suggestions and your views on the above. If somebody wishes to implement some new feature, I'll be glad to provide technical assistance if needed.
André
Hi André!
As far as curved (say high order) panel methods, I think is worth mentioning the work of Prof. Luigi Morino (at U. Boston, but available through NASA TR-Server). One can find even the source code (Fortran IV) of the initial SOUSSA (hyperboloid based) panel method.
Concerning the evaluation of singular integrals, this Morino works and also the works at SAAB-FFA related to their higher order methods (cuadratic panel).
PANAIR theory is open through the same NASA source, and a copy of A502 (Fortran 90) from PDAS (the website of Ralph Carmichael, one of the PANAIR originators).
Further, the works of Dr. John Hess in several articles, and also several reports on MCAERO (cuadratic panel)
Juanjo
Another idea: implement automatic differentiation for the calculation of the stability derivatives. Right now it's done by a simple forward difference, and although the results looks fine, it would be more robust, and nicer, to do it by automatic differentiation. This is how it's done in AVL. I'm not sure that the xflr5 code in its current state allows that, but it will be worth a try at some point.
The first step anyway is to clean the code. I'm doing that right now, and it's incredible how much useless complexity has crept in over the years. I'll commit a hugely simplified v6.10 in January.
André
one really nice thing would be to have a python api for the xfoil-class...
there is pyxfoil already, but it would be really cool to have a nice and clean c++ class...
except for qt-includes i see no obvious obstacles..
thanks for the good tool!
simon
A class such as this one?
https://sourceforge.net/p/xflr5/code/HEAD/tree/branches/xflr5-6.09-07/src/xdirect/XFoil.cpp
yes, a class like this one...
i found the function specal (7647) which might be all it needs except for the public variables (alpha, cd , cw,...)
sorry im not so much into c++, so i did not find those yet (in xfoil.h and foil.h) but i keep looking..
regards!
I know I'm late to the party on this topic, but a bit more on what hiaselhans was suggesting. It would be good if there was a QT free library (libXflr5) which contained the models and algorithms and then have the application use this library so there is a clean separation. This would help in integrating Xflr5 functionality into other projects. I don't mind contributing some time towards this goal.
In v6.10, the GUI, geometry, XFoil, LLT and Panel analysis are all managed
from distinct classes. Technically, I guess it's possible to go a step further and push those classes in separate libraries.
Still, I'm not sure how useful this would be, or how another program would use these libraries. The interfaces would required considerable documentation for the data to be supplied to the library in an acceptable way, and this is a lot of tedious work.
Let me know how you see things, and I'll see what can be done.