OpenVSP

[Heretic]

I've taken the Learjet35A model and tweaked it a bit.

Using the VLM method; the pods on the ends of the wings are causing computational problems; this is quite common in OpenVSP - it can get a bit confused by surfaces that touch at the edge; and in any case a pod isn't really going to give the right sort of results so I've modified the wingshape by adding extra sections that will do the job of the pods.

You also hadn't turned off XZ symmetry on the vertical tail and the ventral fin.

...

Attached is a complete set of files from the run; I did a big run with WakeIterations at 20 - normally I'd be using 3 or 5.

Thank you!

 

[Heretic]

Still not getting to grips with VSPAero. I've implemented Richard's suggestions for my model by comparing his and my original file, but still, the results I'm getting for a C_l-vs-alpha analysis don't show a C_l_max.

I'm trying again on my main PC, this time with the tip tank fuselage objects replaced with simpler pods and the VSPAero solver (11 cases, 5 wake iterations) has been running for a few hours, requires up to 160 iterations per wake and shows no signs of ever finishing.
I can't kill the solver because I'll lose all results it came up with so far and I don't know which case is being worked on because of that dumb auto-scrolling console window.

So the only succesful analysis I've so far has been for the peak frustration coefficient.

 

[Richard Harrison]

As regards the Tornado, the document you indicated shows what inputs are required, but no actual data. I'd love to see some for comparison with what I used.

I can share it confidentially – email me about it.

Sounds like your Tornado FDE is definitely an achievement to be proud of, with the constraints of the tables that are available. I'm not sure how you did it though. Can I get to fly it?

All of that is true, but to the pilot the airplane just rolls without yaw because the CSAS takes care of the issue, so it is not a factor in the simulator. In fact roll is achieved solely by aileron deflection in the simulator model….

I've debated the "why model something that mostly isn't relevant because of stability augmentation systems" and my best answer is still “it depends”.

I prefer to model the aerodynamics and the CSAS as accurately as I can. I’m sure you know this but CSAS can be switched off on the Tornado, as can SPILS.

I do find that on my Tornado there are subtleties that are nice, at high AoA I notice the reduced roll control because the spoilers aren’t doing anything. I don’t know if the CSAS compensates for this by higher differential stabiliser control – I’m guessing it could. With the wings swept in the transonic region I’m getting much less roll due to rudder deflection. On my F-15 and F-14 you can control the various systems that make up the stability augmentation, CAS, pitch and roll ratio controller. Both the F-14 and F-15 come from wind tunnel / flight test data and I had to do it this way, but would probably still prefer to do it this way.

Most if not all flight peculiarities of a particular airplane are not evident to the pilot. If they were

I’m not sure I agree with this – there are a lot of subtleties that can go unnoticed when missing, but when present add to the dynamics. This is all highly subjective, and the only way to definitively check this is by comparison against flight recorder plots – which can be found for a lot of US aircraft that have reports in NTRS. Non US aircraft, well, the data is much more limited.

From watching test pilots during sim acceptance (years ago), it seemed that a lot of the smaller control adjustments are second nature to the experienced pilot – provided the simulator is giving the pilot the right feedback. The pilot doesn't really know if its an aero problem because usually the experience isn't flying in a sterile environment where each flight should be the same, whereas in the aircraft there's a whole load of variables that just don't get simulated. Pilots tended to notice the big stuff that was wrong (such as wing drop at high alpha), and compensate for the smaller errors.

One simulator got through acceptance with a fairly significant spikes in the aerodynamic data due to data entry errors, (e.g. 9.1 instead of 1.9). All of the high speed wing body lift between -5 and 0 alpha (mn 0.2 through 1.2), high speed downwash between alpha -5.0 and -1.6 (mn 0.2 through 1.2) and a few others in the derivatives. Nobody noticed, we didn't have any sort of auto test (QTG) so it wasn't picked up. It wasn't until months later that I wrote something to plot the aerodata as a series of charts (to aid my learning process) and I showed the results to the lead flight modeller that he was almost visibly startled by these plots.

The Hawker Hunter Pilot's notes prohibited deliberate stalls or spins...therefore be an excellent test for OpenVSP

I’ve got a BAe Hawk T2 aero model that I’ve also built with OpenVSP which should also be a good test; this model is older than the Tornado one, and I’ve learnt a lot about how to get the best out of OpenVSP since I made it – so I’ll revisit this one soon and make some tweaks and regenerate to see how it turns out.

Interesting info on the Phantom, thanks for that.

From the simulator point of view you should model the characteristics that will be experienced by the pilot, NOT what the unaided airframe would give you.
…
My most recent and still current FDE project is the Eurofighter. From the airframe standpoint there would be no virtue in modelling …

Either a model of the handling qualities with the stab built in, or model that has more accurate aero and a simulation the appropriate systems (which may not be easy with FSX, I don’t know).

I still believe that OpenVSP has a place in the modeller's toolbox, even for the EFA, you have to start somewhere with the coefficients, it can calculate the mach effects and mass properties.

I also am interested in how you get Scalar on Drag due to mach (max 17 entries) AIR_10XPACK_CD0_MACH given your earlier statement:

I do this by a base run mach 0.6 (it could be anything, but that’s my baseline), then run the same model at the same alphas and take the difference.
Here is the result; compared with the table P3d - http://www.prepar3d.com/SDKv2/LearningCenter/simobjects/sample_code/jet_sample.html I think the P3d is a generic table as it goes up to mach 3.2.

The shapes are similar, but my coefficients are higher – which could be for a number of reasons, maybe because the top left graph is an average of the values across the alpha range for 50degrees of sweep taken from the lower graph. The lower graph has sweep 25,50,60 strung together into one series, so the numbers don't really go back to zero after mn 2.5

As such your list of outputs that could be used as inputs to an air file was very useful though it did not mention the primary lift, drag, pitch, side force yaw and roll records.

I didn’t know about the AIR_80 tables; I’ve since downloaded the (indeed excellent) document you referenced and I still didn’t find reference to these; but they seem pretty standard.

I'm trying too keep this on topic

 

[Richard Harrison]

Still not getting to grips with VSPAero. I've implemented Richard's suggestions for my model by comparing his and my original file, but still, the results I'm getting for a C_l-vs-alpha analysis don't show a C_l_max.

Why not just use the vsp3 I included?

My experience is that you can't use pods at the ends of the wings in any meaningful way. You have to adjust the wings in the way I've done.

For testing only run a couple of points (e.g alpha 0 to 15, inc 5) with wakeiterations at 1, and turn off "batch mode calculation". Also make sure that Vortex Lattice Method (VLM) is selected - panel method is more sensitive to incorrect geometry. I included the .vspaero file that has the settings. A run should take a few minutes with WakeIterations at 1, unless you've got a really poor CPU (I've only got an i7 2600)

 

[Roy Holmes]

Richard,
Lots of good points there.
Before Microsoft revealed the basis of their air file structure in https://msdn.microsoft.com/en-us/library/cc707065.aspx, there was a lot of folklore and mythology about the subject. Actually there were very few surprises in the official document. The main difference between the air file editors before the kimono was opened and after was the names assigned to the Records. Previously (I say that even though most current discussions use the old names) there was no clear structure in the air file. Since the revelation the file appears divided into essential and non-essential entries and their names reflect the version of the sim where they were introduced. For example, AIR_10XPACK_CD0_MACH is a table of zero lift drag versus Mach introduced with FSX Acceleration Pack. That Mach file is unique in that the intervals between entries can be whatever you want whereas in the Mach file Blocks the intervals is 0.2 Mach and the range is a fixed 0 to 3.2M.
There was a Record 1101 which held most of the essential aerodynamics and that later was replaced by what is now known as the AIR_80 tables (They are the first bunch in the sample ASM file) However in most discussions and documents you will find that the old names are more commonly used. For example AIR_80_LIFT_PARAMS is Record 1539 and was a section inside Record 1101.

Can you help me with understanding your drag versus Mach charts. Since these are for CD0 and hence at the one AOA where lift is zero, I'm confused by your references to average Alpha and values from -20 to +20. At 20 AOA and 1.5 Mach I suspect things would be departing from the airframe. While on the subject of drag, most of the airplanes I deal with carry external stores and their drag, or lack of drag when not present, has to also be part of the solution.
Roy

 

[Richard Harrison]

Thanks for the background info.

I misread CD0 as CDO and didn't realise that it was zero lift drag. The technique for generating these would be the same; but probably with more alpha points so that you could select the appropriate zero lift Cd for each Mn. It's also maybe somewhere that OpenVSP maybe isn't that good, as the calculations for form drag are simplified, but the transonic and supersonic equations are apparently quite good.

I averaged the alpha values (for my table) as a quick method to get the shape of the curve.

Stores are usually something that I add in a separate table; but if this isn't available then I suppose you'd have to choose whether or not to include them.

I've also got a set of manually created mach factor tables based on a few reports that I used on the F-14. These maybe useful as you can use these tables to create mach tables.

 

[Heretic]

Why not just use the vsp3 I included?

Learning by DIY.

My experience is that you can't use pods at the ends of the wings in any meaningful way. You have to adjust the wings in the way I've done.

Maybe I should notify the developers about the unusability of pods or do they already know?

For testing only run a couple of points (e.g alpha 0 to 15, inc 5) with wakeiterations at 1, and turn off "batch mode calculation". Also make sure that Vortex Lattice Method (VLM) is selected - panel method is more sensitive to incorrect geometry. I included the .vspaero file that has the settings. A run should take a few minutes with WakeIterations at 1, unless you've got a really poor CPU (I've only got an i7 2600)

Why no batch mode?

And out of curiosity, does the selected Mach number play a significant role for the results?

Available CPU power isn't much of an issue (i5 4670 @ 4.2 GHz and an i7 6700HQ), but the solver takes ages with the pod tanks and a high tesselation value for the parts.

 

[Richard Harrison]

Ah ok; I can understand why you want to get to grips with it yourself. I'd still suggest having a go with the way I did the wings, or removing the pods. Generally it's better to start with a fairly simple model and refine it. You could probably do the entire horizontal tail as a single wing section and it might give you better results.

VLM is a simplified way (compared to CFD) of calculating results, so by adding model elements one at a time you can see what the changes are, and also work out when adding something breaks the calculations.

I'm not exactly sure about this; but I think pods are more suited when you need to make a cfd mesh. My comment is based on the results from VSPAero for pods. I spent roughly 6 months last year figuring out how to get meaningful results from VSPAero - and this is why I don't use pods much except for external stores where it's mainly drag. You can always ask on the OpenVSP group about pods.

If you don't select batch mode then you'll see each alpha/beta/mach appear on the results graph when that part of the run has finished. It has the disadvantage that you'll only be able to use the viewer on the last run.

Mach number does indeed have an effect that you can notice whilst flying. I'm still not sure if it's right; but it certainly feels different and I intend to devote more time to figuring out if it is right or not. At the moment all I can say is that it seems to be about right for the Tornado, but I have very little to compare against.

 

[Roy Holmes]

The Hunter T7 had a side by side cockpit and at around about 0.92 Mach at low level on a humid day you could see a shock wave coming off the top of the canopy just above your head.
That was a Mach effect you noticed! Slight fore-aft stick movement caused it to move back and forwards.
Roy

 

[Heretic]

VLM is a simplified way (compared to CFD) of calculating results, so by adding model elements one at a time you can see what the changes are, and also work out when adding something breaks the calculations.

Yes, it is much simpler. I've worked with OpenFOAM before and even a simple tube with adequate meshing (Courant < 1) does take some time to complete. I'd probably need a separate PC and lots of time if I was to run an aircraft model through that.

I'm not exactly sure about this; but I think pods are more suited when you need to make a cfd mesh. My comment is based on the results from VSPAero for pods. I spent roughly 6 months last year figuring out how to get meaningful results from VSPAero - and this is why I don't use pods much except for external stores where it's mainly drag. You can always ask on the OpenVSP group about pods.

I might just do that, but the devs seem to be on a break at the moment (still have an unanswered topic in the group).

If you don't select batch mode then you'll see each alpha/beta/mach appear on the results graph when that part of the run has finished. It has the disadvantage that you'll only be able to use the viewer on the last run.

Intermediate results were one of the suggestions I've made for future improvement. Never knew that it was batch mode that holds results back until the solver has finished.

 

[Richard Harrison]

Yes, it is much simpler. I've worked with OpenFOAM before and even a simple tube with adequate meshing (Courant < 1) does take some time to complete. I'd probably need a separate PC and lots of time if I was to run an aircraft model through that.

From http://www.cobaltcfd.com/pdfs/AIAA_2006_0901_F15spin.pdf - In 2006 using 1024 processors gives 5 seconds per CFD iteration. An aeromodel requires around 10k CFD iteration this works out at roughly 631 CPU Core days, so a modern high spec server can probably do a full aero run in 26 days (this is a rough guess of CPU speed increase since 2006 and assuming at 24 cores). This pretty much makes CFD out of reach for most of us, except maybe for limited models or smaller runs. I do plan (one day) to setup an OpenFOAM model and see how it works out.

 

[Heretic]

From http://www.cobaltcfd.com/pdfs/AIAA_2006_0901_F15spin.pdf - In 2006 using 1024 processors gives 5 seconds per CFD iteration. An aeromodel requires around 10k CFD iteration this works out at roughly 631 CPU Core days, so a modern high spec server can probably do a full aero run in 26 days (this is a rough guess of CPU speed increase since 2006 and assuming at 24 cores). This pretty much makes CFD out of reach for most of us, except maybe for limited models or smaller runs. I do plan (one day) to setup an OpenFOAM model and see how it works out.

Good luck with that.


By the way, do you per chance have something to post-process OpenVSP's output files with?
The structure of the data in the .csv file is not really usable without some rearrangement after import into LibreOffice.

 

[Richard Harrison]

I don't have anything that processes the .csv files - my application uses the history files and scripts VSPAero to do the work, but it needs a lot of work before I could release it; and I'm not certain it's even the right way to do it with all of the recent improvements in OpenVSP relating to batching.

 

[Heretic]

Too bad. Thanks anyway.