VSPAERO convergence

[Philipp P.]

Hello,

I want to simulate the Do228 wing with VSPAERO. I  have added the original airfoil and wing parameters.

However I am experiencing that the simulation is not converging. Values like CDi and CL are constantly changing even after 100 wake iterations and a high number of spanwise tesselation. 

Maybe it has something to do with the airfoil? What is a typical number of wake iterations?

I added the vsp3-file fo a better understanding of the problem.

Thanks!

Philipp

[Rob McDonald]

I think your expectations for convergence are misaligned with VSPAERO.

For a simple isolated wing, most of the time, we consider VSPAERO converged after two or three wake iterations.  Look in the *.history file and see which digits of precision are changing vs. staying the same.

You only need more iterations when you're working with complex wing/tail combinations (even that is really simple) or something with a bunch of propellers blowing the wing, or something with a very complex wake structure.

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philipp P.]

In addition to that I am trying to find the optimal tesselation that gives me good results at low computational cost. 

Unfortunately, I am always getting different results no matter what tesselation I choose. The value for CDi varies between 0.0226 and 0.0236 and it seems to be impossible to find "the one correct" result.

Philipp

[Philipp P.]

Thanks for you fast response.

I was simulating propellers blowing the wing in the first place. But I went back to the isolated wing to find the issue concerning the changing values. 

Philipp

[Brandon Litherland]

Philipp,

I've done some convergence studies using a prior version of VSPAERO (before 3.16.1 release) and have found the following.

For simple wings in isolation, you aren't getting any additional useful information by setting the Num_W tesselation beyond 61, maybe 81 if you really think that you need it based on your LE/TE clustering.

As with any numerical solver, you want your lattice or grids to be relatively close to an aspect ratio of 1.  This implies that your spanwise, Num_U, spacing should be set up according to your span and clustering intentions.  The SectTess_U parameter is limited to 100 so if, and a big IF, you decide that you need more than 100 spanwise sections, you will have to split into a multiple section wing, but I don't recommend this.

More relevant to your issue is that you want to put high cell concentration where most of the gradients are e.g., wingtips, behind propellers, wake interactions, etc.  This is true for both panel mode and VLM mode.

Another thing you might try is changing the base units of your model.  I've found that scaling everything to inches gives more steady results which leads me to think that there is a fixed decimal truncation somewhere in the normalization of values in the code.  You can get a 10^-2 residual difference this way.  Remember that OpenVSP operates in a relatively unitless fashion (length normalized) so you'll want to change the velocity and other flow inputs to match the units that you are using.  I'm not sure if the Reynold's number in VSPAERO is length normalized or not.  I've always assumed that the value of ReCref implies Reynold's based on reference chord.

Assuming that you are trying to find the best "wall time" for a large batch operation, here is something else to consider.  Check the actual specs of your machine, either on your PC or server, and find out the number of cores per processor (right click Computer and Google the processor).  Machines today use hyperthreading so you have additional "virtual cores" available.  For example, an Intel i5 processor has 2 physical cores and 2 virtual cores for a total of 4.  Num CPU will use up to this number of threads but no more.  Here's where it gets fun.  Hyper-threading actually slows down VSPAERO past a certain threshold.  The calculations are so fast that the act of passing information between virtual and physical cores takes longer than the solution.  If you run on a server with 40 (20 + 20), you'll find that trying to run on 20 cores will take MUCH longer than just 10.  On a laptop, it doesn't matter much because you're only threading between two cores so who cares.  Just set Num CPU to 4 and let it chug.  But on a server, say with two 10 physical core processors, you want to set Num CPU to 10.  This keeps much of the calculation to one physical processor and runs very quickly.  3 minutes compared to 10-15 minutes using NumCPU at 20.

Rob is absolutely right about the number of wake iterations.  For simple wings in isolation, you only really need two.  Three for a sanity check if you like.  For propeller interaction or complex geometries/combinations, you'll use 5 to 7 but should never really need more than 10.  What you should be checking is the History file and the convergence plot of the log(residual).  You'll see that it quickly drops to around 10^-4 or 10^-5.  Past that is just noise for the methods used.  If you watch the GMRES iterations in the solver window, it shouldn't take long to get a 10^-1 drop in residual.  Look at Reduction and Maximum.  VSAPERO considers a wake iteration converged when it sees a Reduction by -1 (think 10^N, it's trying to reduce the residual by a factor of 1/10) and Maximum tracks the overall residual reduction (you'll see something like -3 or -4).

Some final words of advice.  Check your actual airfoil points and look for highly clustered points near the LE or TE.  This can cause issues in the solution.  Drop it into XFOIL and respline the points into something more reasonable (140-200 points total) and you should be okay.  The types of convergence that you can get with StarCCM, FUN3D, OVERFLOW, etc. are way beyond the scope of this level of analysis.  It's overkill.  If you're looking at a GA or commercial a/c, how much of a difference is 0.001 in CL?  On a 10k lb small vehicle, it's about 5 lbs.  On a larger 100k lb a/c, it would be 50 lbs.  A 0.01% difference in lift.  Even if you have residual differences at the 10^-2 level, it's a very small physical difference.

A lot of this is probably beyond the scope of what you need to know, but this seemed like an easy enough way to put the information out there before I formalize everything in an online training program.  Hope this helps.

Cheers.

[Brian]

Brandon,

Thanks a lot for the in-depth post!  I was looking for this kind of information just yesterday.

Brian

[Brandon Litherland]

Typed the percent difference in error.  It would be a 0.05% difference.  For a 737-Max at 30k feet, the difference would be 0.2%.

[Philipp P.]

Brandon,

thank you very much for the detailed answer, This brings some light into darkness. 

Which one of the residuals is key here? The log10(L/D)? 

I checked my airfoil which seems to be okay and adjusted the grid for cells of an spect ratio around 1.The picture below shows a screenshot of my result with 10 iterations. Would you consider this as convergent?

Philipp

[Brandon Litherland]

Philipp,

The image is a little fuzzy so it's hard to see the grid lines at the bottom.

However, it looks like you're result is hovering around 10^-2 or 10^-3 residual of L/D.  That's not too bad.

You'll get a better idea of what is going on if you look at the residual of CL and CDi or your CFx,y,z values.  The images below are from your original DO228 model, CDi and CL respectively.

This runs quickly so you can check it yourself if you like and watch the behavior.  Try running w/ X-Z symmetry on to cut your solver times in half.

Also, you can set your plot axes' max/min values under Actions in the Results Manager Plot.

Notice how the residual NEVER drops below 10^-5.  That is the truncation I was talking about.

If you turn off the residual flag under Actions and look at the progression of the values, you'll see that by iteration 3 you are dealing with errors of around 1 drag count (CD x 10^4).  I did a test to 100 wake iterations and the average CDi was about 0.02472 with a maximum error from that of plus/minus 0.00015.  Looking at CL for the same run I saw about 0.8081 as the average with deltas around 0.0006.  Not bad for 100 iterations in less than 5 minutes.