Re: [OpenVSP] Unsteady single rotor in hover

201 views
Skip to first unread message

Rob McDonald

unread,
Dec 9, 2019, 11:49:56 AM12/9/19
to ope...@googlegroups.com
When you start a true hover case (V=0), it takes a while for the downwash flowfield to get established and to convect the local wake activity downstream.

VSPAERO has an option to start a hover analysis at a finite velocity, to help convect the startup vortices downstream.  As the solution progresses, it ramps the velocity down until it meets the specified Vinf.  This will work for any case with a small velocity -- not just pure hover.

-hoverramp V1

I suspect using this will help make your low-velocity cases a lot more consistent.

Rob

On Mon, Dec 9, 2019 at 6:16 AM Will <w.j.r....@gmail.com> wrote:
Hi Rob,

I was hoping you could clear a couple of things up for me. I am currently modelling a single rotor in hover using the unsteady VLM within VSPAero. I have the rotor rotating about the Z-axis at a constant RPM. When I dig into the .rotor output file, for example, the thrust values are very sensitive to the cross flow velcity, Vinf. The thrust value will change a number of order of magnitude when chagning Vinf between 1 m/s and 5 m/s. I am also interested as to why it seems the UVLM can't handle hover condition, Vinf  = 0? I would have assumed the UVLM could deal with this scenario?

Kind regards,
Will

--
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/cb84ec60-be2a-4324-a11e-b467f991790f%40googlegroups.com.

Will

unread,
Dec 10, 2019, 4:13:07 AM12/10/19
to OpenVSP
Hi Rob,

Hoverramp seems like it will be useful, thank you!

If I try and run the command as follows:

 vspaero -omp 12 -hoverramp 5 x_DegenGeom    

I get a segmentation fault before the first iteration. Am I using this incorrectly? Also if I put the -unsteady flag before -hoverramp, it seems to ignore it.

Also I still will always get a segmentation fault using the uber testcase (or my own). On the linux distribution I can make it through the uber example provided (150 iterations) however it will rarely complete 500 iterations without a seg fault. Not sure if this is a bug?

Thanks
Will


On Monday, 9 December 2019 16:49:56 UTC, Rob McDonald wrote:
When you start a true hover case (V=0), it takes a while for the downwash flowfield to get established and to convect the local wake activity downstream.

VSPAERO has an option to start a hover analysis at a finite velocity, to help convect the startup vortices downstream.  As the solution progresses, it ramps the velocity down until it meets the specified Vinf.  This will work for any case with a small velocity -- not just pure hover.

-hoverramp V1

I suspect using this will help make your low-velocity cases a lot more consistent.

Rob

On Mon, Dec 9, 2019 at 6:16 AM Will <w.j....@gmail.com> wrote:
Hi Rob,

I was hoping you could clear a couple of things up for me. I am currently modelling a single rotor in hover using the unsteady VLM within VSPAero. I have the rotor rotating about the Z-axis at a constant RPM. When I dig into the .rotor output file, for example, the thrust values are very sensitive to the cross flow velcity, Vinf. The thrust value will change a number of order of magnitude when chagning Vinf between 1 m/s and 5 m/s. I am also interested as to why it seems the UVLM can't handle hover condition, Vinf  = 0? I would have assumed the UVLM could deal with this scenario?

Kind regards,
Will

--
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 ope...@googlegroups.com.

Rob McDonald

unread,
Dec 10, 2019, 11:22:09 AM12/10/19
to ope...@googlegroups.com
Not sure on the details of using -hoverramp.  I haven't had time to use it myself.

I would probably use a larger initial velocity.  If you have an estimate of CT and/or the hover inflow velocity, I would probably start with a value about that magnitude.

Justin and Dave found a bug related to the other test case crashing -- it will go into the next release.

Are you set up to compile yourself?  We could make it available on GitHub if you can build it yourself.

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/9404bfe7-f284-4f22-8ee8-14cf072d4cb5%40googlegroups.com.

Will

unread,
Dec 12, 2019, 9:30:23 AM12/12/19
to OpenVSP
Hi Rob,

I am able to compile myself, it would be great if you could make it available on GitHub!

I've still had no luck with hoverramp, but for now having a more stable release would be really helpful!

Thanks
Will


On Tuesday, 10 December 2019 16:22:09 UTC, Rob McDonald wrote:
Not sure on the details of using -hoverramp.  I haven't had time to use it myself.

I would probably use a larger initial velocity.  If you have an estimate of CT and/or the hover inflow velocity, I would probably start with a value about that magnitude.

Justin and Dave found a bug related to the other test case crashing -- it will go into the next release.

Are you set up to compile yourself?  We could make it available on GitHub if you can build it yourself.

Rob


Will

unread,
Dec 16, 2019, 10:46:20 AM12/16/19
to OpenVSP
Hello Rob,

Would it be possible for the bug fixes to be pushed to GitHub? 

Thanks
Will

On Tuesday, 10 December 2019 16:22:09 UTC, Rob McDonald wrote:
Not sure on the details of using -hoverramp.  I haven't had time to use it myself.

I would probably use a larger initial velocity.  If you have an estimate of CT and/or the hover inflow velocity, I would probably start with a value about that magnitude.

Justin and Dave found a bug related to the other test case crashing -- it will go into the next release.

Are you set up to compile yourself?  We could make it available on GitHub if you can build it yourself.

Rob


Rob McDonald

unread,
Dec 16, 2019, 3:54:32 PM12/16/19
to ope...@googlegroups.com
I've been working on improving our automated build stuff to improve the release process.  In that, I've hoped that I would be able to make a release very soon (actually days ago).  Unfortunately, I'm making slow progress at best.

The commit you want is this one.  You can build that branch (Next) and get some more stuff -- or just cherry pick that change -- or (as it is simple enough), you could just modify your local file manually.

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/843eaff0-103e-447b-8686-ee396fda1d60%40googlegroups.com.

Will

unread,
Dec 16, 2019, 5:59:52 PM12/16/19
to OpenVSP
Thanks Rob, I have modified my file locally and rebuilt. Hopefully this will fix the seg fault issue.

Really appreciate all your help!


Thanks again,
Will 

On Monday, 16 December 2019 20:54:32 UTC, Rob McDonald wrote:
I've been working on improving our automated build stuff to improve the release process.  In that, I've hoped that I would be able to make a release very soon (actually days ago).  Unfortunately, I'm making slow progress at best.

The commit you want is this one.  You can build that branch (Next) and get some more stuff -- or just cherry pick that change -- or (as it is simple enough), you could just modify your local file manually.

Rob


Reply all
Reply to author
Forward
0 new messages