Vspaero crashes to compute propeller geometries

115 views
Skip to first unread message

Vinicius Moretto

unread,
Aug 18, 2021, 4:58:31 AM8/18/21
to OpenVSP

Hello everyone,

 

I’m using OpenVSP for simulate a propeller in an optimization procedure. For that, I’m using the OpenVSP python API version 3.25.

However, I'm having problems with some geometries. When I try to calculate the geometry ("VSPAEROComputeGeometry" analysis), vspaero crashes and I get no response. As a result, the code that I’m written keep waiting for some update, which doesn’t happen anymore.

 

I’ve tried some solutions to solve this, but still haven't found a good one. I was thinking about setting a “timeout” to avoid this kind of problem, so when it happens the code just wait some time and then pass to other geometry, but I didn’t found a way to make this possible. Do you have any recommendation on how can I do this? Is it the good option? Do you if there is any “native” OpenVSP function to do this sort of thing?

 

I notice when I change the mesh discretization (Tess U for example), vspaero runs smoothly, so an option is also know when this will happen before launch the analysis, but is there any way to predict this? Why does it happen?


I’m submitting an example where vspaero crashes to generate a DegenGeom.

 

Thanks in advance!


Example_crashed.vsp3

Brandon Litherland

unread,
Aug 18, 2021, 7:56:36 AM8/18/21
to OpenVSP
I can recreate the behavior that you describe.  Not only does altering the tessellation fix it but if you change the diameter  to 1.0 or 0.25 it works fine... so I doubt that the geometry itself is the issue.  
You can also display the Camber Degen surface with no issues.  I can see how changing the tessellation might fix the issue but the size should have nothing to do with it.  Very odd.

In the meantime, I recommend using Num_W = 33 instead of 25 to get around this.

Vinicius Moretto

unread,
Aug 18, 2021, 10:37:58 AM8/18/21
to OpenVSP

Yes, there are different parameters that we can change and the simulation runs. In this same file I  just add 0.0001 to the Camber Location of the XSec_0 and it works fine.

Then I did the same thing on the following parameters (add or subtract a very small value like 0.0001) and it worked for all of them. I only changed one parameter at a time.

   Diameter; Toc_0 (thick); Toc_1 (thick); Toc_2 (thick); CLi_0; CLi_1; CLi_2; CamberLoc_0; CamberLoc_1; CamberLoc_2

This is weird to me because the modifications were subtle and geometry pretty much unchanged, but DegenGeom worked.

About using Num_W = 33, I’m afraid to find another set of parameters that also crash the code. I’m running an optimization now with Num_W = 33. Let’s see if it works.

Rob McDonald

unread,
Aug 18, 2021, 1:52:27 PM8/18/21
to ope...@googlegroups.com
I was not able to get this case to crash on my computer (MacOS) through the GUI.

I know Brandon was able to duplicate the problem, but if you could provide test cases with easily replicable steps, that will always be best.

I noticed that your prop had many points defined out the span for chord and twist.  It was likely designed in some sort of BEM and then imported (or manually, or API) set to match.  Once you pull in these points, I recommend you convert the curve type to 'Approximate Cubic Bezier'.  This will fit a cubic bezier to your points -- this should keep the shape essentially the same while reducing the computational burden of modeling the prop.  In addition, if you want to make further modifications to the shape, you can more easily tweak it with the reduced parameterization.

Likewise, I noticed that you are using NACA 4-digit foils all the way out the span of the prop -- this is the easiest and most straightforward way (to use a single airfoil type for the entire blade).  If you are doing this, I would delete the middle airfoil XSec specified -- it doesn't contribute anything.  The foil shape is still described through the t/c and cli curves

I noticed that your model appears to be very small -- which may mean that it is expressed in large units -- perhaps meters.

Sometimes, the kinds of crashes that you're seeing are more prevalent for models that are extreme in scale (large or small).  You might try modeling your geometry in cm or mm to see if that helps with these crashes.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/7374d325-a606-4ff6-b368-063f267e4013n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages