Re: [OpenVSP] Panel method errors

[Rob McDonald]

Control surfaces don't work in panel mode -- only VLM.

When an object disappears from the model going to panel method, it is because CompGeom (a step in the process) found that the objects were not water tight -- it drops open objects.  All components of your geometry should be self water tight.

When learning VSPAERO, I strongly suggest you start with simple cases, develop some confidence, and slowly make them more complex.  Get a feel for what mesh resolution is required.  Get a feel for what works well and what does not with the geometry.

Jumping directly to very complex cases is a recipe for frustration.

Rob

On Sun, May 10, 2020 at 7:58 PM FM <kingd...@gmail.com> wrote:

I have added control surfaces to the model and tired to solve using the panel method but, it makes the wing disappear when  the mesh is formed. I'm not sure why

Also, I have been referencing to results from a wind tunnel test report (on the aircraft my model is based on) but, the Cl  and Cd results from that are quite different to both my panel method and VLM method results. I was not expecting accurate results but the error is abnormally high. 

I've attached the model and results to the post.

Moreover, I have made a scaled model of the aircraft and when I test that, the programme crashes. I have deduced that it is because of the nacelles but, I am not sure why it effects the method since, on the regular scaled model the VLM method runs fine. 

Thanks in advance 

--
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/5a0174a0-b130-4885-8346-888ccc30decc%40googlegroups.com.

[FM]

I fixed the water tight error.
 I Have had practice on more simple models and think I am able to create a more complex model. Also this is for a project I am working on.

For the Cl results do they seem reasonable to you? To me they seem to be slightly lower than expected.

For propulsion is there currently any advantage by using the modelled propellers in-comparison to the actuator discs. Are the drag results from the modelled propellers any good?

Also, for the wake generation how is it computed on OpenVSP.

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Rob McDonald]

I think you don't have sufficient spanwise resolution on your wing to get meaningful results.  Experiments with a simple wing would give you experience to figure out what kind of resolution you need to get results that you can have confidence in.

The actuator disk model can not model the details of a blade spanwise load distribution.  It achieves a steady solution that does not represent the unsteadyness caused by finite blade rotation.  On the other hand, in order to use the rotating blade model, you need to know a lot about the blade geometry details.  This information is often not available -- and an actuator disk approach lets you skip a lot of details.  It should also be much cheaper.

Rob

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/d23489cb-3a61-4465-b347-b94cb10f651a%40googlegroups.com.

[Ole Ber]

Hi Rob,

It would be greate to have the Panel Code available for the rotating blade Mode. VLM, as well as actuator disc models are no options for e.g. ducted propeller analysis or propeller wing interactions.

Ole

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/d23489cb-3a61-4465-b347-b94cb10f651a%40googlegroups.com.

[Rob McDonald]

The panel mode should work for rotating blades (though I think there may be a short-term bug right now).

What is unavailable - and no immediate plan to fix - is the ability to post-process calculate the spanwise load distributions on the thick surface panel models.

The rotating blade thin surface approach is similar to approaches used by most comprehensive tools used in the rotorcraft community.  These often capture interaction effects.

The actuator disk model (even with VLM) is actually pretty good at prop-wing interactions -- so long as this is a cruise-like case rather than a case where the wing significantly turns the propeller slipstream.

I've actually been surprised how well the actuator disk does with a ducted fan -- it really shouldn't work, but did a reasonable job.  I have used VSPAERO to do a panel-method ducted fan analysis before -- but I was using the axis-symmetric steady rotating frame mode rather than the unsteady rotating blade mode.

Rob

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/37fba87b-53b9-4b34-80fe-e60f82773307%40googlegroups.com.

[FM]

When I tripled the number of points span-wise, the results stayed the same.

For panel method I'm getting a zig-zag result for Cl. I'm not sure why. The discs weren't included. 

Is it possible to complete a gust loading test on Openvsp 

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/37fba87b-53b9-4b34-80fe-e60f82773307%40googlegroups.com.

[Rob McDonald]

Why are you running up to 40 degrees aoa?

Try running a sweep from zero to 10.

Look at your lift distributions.  Are they reasonable?

Look in viewer.  Are your solutions reasonable?  Are your wakes what they expect?

Rob

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/ac1a3045-09a1-4217-93ba-50df2f9406a1%40googlegroups.com.

[FM]

When I add all the components, the launch viewer does not seem to open 

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/ac1a3045-09a1-4217-93ba-50df2f9406a1%40googlegroups.com.

[Rob McDonald]

It won't open if it is already open.  Make sure you close it from a previous run before trying to open it again.

Other than that, it won't open if there isn't a successful solution file from a previous run -- did your run crash?

Rob

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/66b03a6a-b6b2-49c3-bfd0-f888d66bc9cf%40googlegroups.com.

[FM]

I have closed all my windows before running the test. I don't think it crashed since, I was able to view the results. I do notice that it there a lot of components it tends to not open.

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/66b03a6a-b6b2-49c3-bfd0-f888d66bc9cf%40googlegroups.com.

[Rob McDonald]

Please provide an example case that fails to launch the viewer.  You are the first to report this problem.

Rob

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/171e2ca5-214a-4180-ac55-b3919cc74f23%40googlegroups.com.

[FM]

I had to direct message the file because it said the group limit file sharing had been reached were you able to see it.

[Rob McDonald]

When you launch VSPAERO in panel mode, OpenVSP creates a MeshGeom that it sends to VSPAERO.  If you save that model, OpenVSP will store that mesh in the model -- making your file very large.  You probably want to delete the MeshGeom after each VSPAERO run.

When I ran this model, VSPAERO crashed.  However, it still allowed me to run viewer -- the model opened, though there was no sensible solution -- because the solver crashed.

I'm not sure what caused solver to crash - I don't have time to dig in much.

However, you do not have appropriate spanwise resolution on your wings.

Rotating blades are a little broken right now for thick-surface panel mode, so you should switch to VLM or to actuator disk.  I'm not sure if this is the root of your crash or something else.

The way to figure these things out is to start with a simple case, develop some confidence, and gradually make your case more complex.

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/2cc06406-49c8-4cbd-ab71-4d0580caa730%40googlegroups.com.

[ReynoldsNo]

Hi Rob, 

   With regards to the 13 May, 2020 discussion saying "Rotating blades are a little broken right now for thick-surface panel mode......"

   I was wondering, do rotating blades work for thick surface panel mode?

   If not, is there a way to run VLM for the rotating blades combined with panel mode for the rest of the aircraft??

   

   Thanks

[Rob McDonald]

This may get a little confusing...

There have been three file formats for communicating between OpenVSP and VSPAERO.  DegenGeom, *.tri, and *.vspgeom.

With DegenGeom and *.vspgeom, VSPAERO knows exactly where the trailing edges are.  With *.tri, VSPAERO has to guess where the TE's are, and it would get things wrong for lifting rotors.

Overall, we are trying to move everything to *.vspgeom files -- we are not there yet.

In the 'old days', VLM mode communicated through DegenGeom and Panel mode communicated through *.tri.

Then, for a period, the default was the same behavior, but the 'Experimental File Format' would use *.vspgeom for both VLM and Panel modes.

We have gained comfort with *.vspgeom for Panel method -- but we still prefer DegenGeom for VLM mode.  So...

Recently, we switched to use *.vspgeom for Panel method by default and *.tri as an 'Alternate File Format'.  However, for VLM, the default is still DegenGeom, and it switches to *.vspgeom when you use 'Alternate File Format'.

So, assuming you are running an OpenVSP recent enough that the Advanced option is labeled 'Alternate File Format' (not Experimental File Format), then you should _not_ use Alternate File Format for either VLM or Panel -- your rotating blades cases should work fine either way.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/f5ac2466-f89a-479e-8550-3bfb5013f2d8n%40googlegroups.com.

[ReynoldsNo]

Hi Rob, 

   Hmmm.  So here is the specific issue that I am having.  I am doing some fundamental validation for rotor modeling 

   using the following model downloaded from the OpenVSP Hangar (https://hangar.openvsp.org/vspfiles/526)

   I am running OpenVSP-3.31.1

   I have made a slight modification to the wing TE closure in order to have a sharp trailing edge for running in panel mode. 

   I have no problems running VLM for 

      isolated wing

      isolated propeller

      wing + propeller

   I have no problems for running in Panel mode for

      isolated wing (i.e. trailing edge closure is ok)

   Problems show up when I activate the wing and mid-prop and try to run in Panel mode.

   I start getting errors like:

   Isolated propeller:

      -nan 

   Wing + Propeller

      ERROR 7: Could not open Polar file:.........  *VSPGeom.polar

      ERROR 7: Could not open Load file: .......    *VSPGeom.lod

There is something I am fundamentally not understanding about setting up a run in panel mode with propellers.

I have attached the *.vsp3 file that I am using.

Please advise. 

Thank you!

[Brandon Litherland]

Unfortunately, I had this figured out at one point and now I can't recall exactly what I did to spin panel rotors.  I know I had to run VSPAERO from the command line and modify the Groups file.  However, the results would not be as reliable as VLM anyway so I stopped testing.  I can try to figure out how to get them spinning over the break.

[Rob McDonald]

I suspect there is a bug creating the *.groups file as Brandon alludes...

You might be able to play around with it and get it to run from the command line.  It will take some time for me to sort out.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/9508e03c-1050-4efb-814a-b129ff02d4b1n%40googlegroups.com.

[ReynoldsNo]

No worries.  Thank you all the same. 

The VLM simulations will be just fine for me too. 

[Rob McDonald]

Quite frankly, I would have preference for the VLM method for this case no matter what.

It does a really great job with lifting surfaces -- I would only want to push for the panel method if there was a thick fuse-like body causing significant blockage in this case.  However, since it is all props and wings, I think you're in great shape using VLM.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/6c116893-253e-4d2d-abc9-6908da277e10n%40googlegroups.com.

[Brandon Litherland]

Following up, I've tested two different wing-prop models and found that unsteady panel methods works as expected for both.  You should be able to test this by creating a default wing, add a Prop and set Dia to 5, run panel unsteady mode at about 2000 RPM.  I've attached a modified example that _should_ work right out of the box.  Just open the VSPAERO GUI and click Launch. Back around version 3.26 or so this was still a problem but in recent releases had been fixed.  So it begs the question of why the midspan wing-prop model from the Hangar is busted.  I suspect there is some small artifact that I'm missing that is giving panel mode fits rather than a Groups bug this time, particularly since the viewer is accurately showing the 5 blades in the same group as expected.  Digging into this a bit more as time permits.

[ReynoldsNo]

Thank you very much for all the help. 

I will have a look at the model that you have provided. 

[Franco Staub]

OpenVSP Team,

I am working on a hybrid wing body config and have found some strange spanwise lift distributions only when running the panel method (VLM works like a charm). See the image for what I am talking about. I have tried many things to reproduce the error on a simplified geometry, but the only thing that seemed to trigger it was having a multi-section wing with a large taper and change in sweep at the mid-span. Some other info that I found odd is that the CP distribution shows a strong suction at the tip TE (these are all symmetric NACA airfoils), and the wake lines have some sharp turns where they come off the center section TE (see images).

I have tried:

-changing scale of the geometry (using inch numbers vs ft numbers)

-changing spanwise and chordwise tesselation (more tesselation tends to aggravate the spikiness of lift distribution)
-using a variety of airfoils, including built-in ones (was suspicious my custom airfoil TE were not closed properly)

-changing the blending (original had a lot more blending)

-changing root/tip cap treatment (thought this might be another source of a leak)

-varying flow conditions (Mach and AoA)

None of these had an effect on the spiky lift distribution. I have attached the vsp3 file and am running 3.34.0. I hope that gives enough information.

Thanks always,

Franco

[Franco Staub]

Hello OpenVSP team,

Sorry for the persistence, but I wanted to check in to see if there is any feedback on this issue. I am eager to explore the panel method and the new control surface functionality built into it. 

Kind regards,

Franco

[Rob McDonald]

The panel method won't support control surfaces for some time -- that has not been released.

The load distribution and Cp distribution are post-processed results.  Things like jagged load distributions may not mean there is any problem with the solution.

For this BWB type shape, I see no reason to prefer the panel code over the VLM -- I would use the VLM.

When I have seen things like this, it is usually associated with rapid spanwise changes in behavior -- often twist.  I would make sure I had smooth spanwise resolution and I would also try a version of the file with symmetrical airfoils and no twist...

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/63e5f12b-3a12-4c66-b82b-8a288922c892n%40googlegroups.com.

[Franco Staub]

Hello OpenVSP Team,

This may be a low priority thread, but I was wondering if anyone ever got to looking at the root cause of the post-processing issue. For additional context, I have tried a variety of spanwise resolutions but got the same results. As for using the VLM instead - yes, that works sufficiently for the longitudinal axis. However, I am interested in seeing directional characteristics (i.e. Cnb, Cnr, etc). I think the panel method would shine here since it captures thickness effects of the center body on directional stability.

If you point me to the post-processing script, I may be able to investigate in my spare time.

Best wishes,

Franco

[Amid]

I'm new to OpenVSP and I'm trying to create a model of my concept. For the fuselage, I tried running VSPaero using both the VLM and Panel methods. In both cases, I got odd results, and at the end of the calculation, it showed me that the mesh might not be closed. I would appreciate it if you could check the attached file and let me know what is wrong with my model.