Sections in BOR - Possible?

[Ismeret Tenger]

It is a feature request.  BOR at this moment has no sections or XSecs.  For one of my little projects it would be useful to have a BOR with minimum 2 sections and those sections to have different airfoils on them.  Any such plans for the near future?

Thanks ahead,

János

P.S.  If I have a coax rotor setup, VSPAERO shoes the FOM - I guess Figure of Merrit - zero for the second rotor.  See attached.  Is that a feature or something else?

[Rob McDonald]

I don't understand what you are trying to achieve with a BOR with two sections.  By definition, a BOR is a profile revolved around an axis -- that makes the cross sections circles...

What are you actually trying to achieve?  Possibly post a sketch or an example.

I haven't tried a co-axial rotor with unsteady blades like that -- co-rotating or counter-rotating?  I am surprised that FOM would be zero, but it is also possible that the solution did not work out well.  Does the wake structure in vspviewer make sense?

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/4e259a7b-2213-42e1-a7cb-25c6ae7e9f88n%40googlegroups.com.

[Ismeret Tenger]

Hi Rob,

Regarding BOR think about the Delta 7B flyer you sent to me.  The ring has the NACA 0010 profile.  It has no camber, so at alpha=0 it does not generate any lift.  If I want it to generate some lift even at alpha=0, I need minimum a NACA 1xyz airfoil.  The problem with it is, that it will generate lift on the upper half ring and an equal negative "lift" on the  lower half, so it is almost like with camber 0 except the stress created at the connector to the lifting body.  If the BOR would have minimum 2 sections than I could invert the airfoil on the lower half, so in total the ring would generate lift even at alpha=0.  Of course four sections would be nicer, because I could morph better the two half at the ends of the connector.

The blades on my Texas-style windmill are counter-rotating.  The graphical representation of the wake structure looks to me right for both rotors, and it shows that the second rotor on the back is hitting already disturbed air, so related coefficients are mostly showing it, with some exception like the FoM, I mentioned.

[Rob McDonald]

OK - I understand what kind of geometry you are thinking of.

it is not a BOR because by definition a BOR is a single curve revolved about an axis -- all cross sections of a BOR are circles (or multiple circles).

Your shape will have non-circle cross sections.

There is currently no plan to implement the shape you describe.  It wouldn't be terribly difficult to do.  If you want to take it on yourself, I can give you some pointers.  The first step would be getting set up to compile OpenVSP on your own.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/f486eb07-efb1-4215-b7fe-5b5128511367n%40googlegroups.com.

[Ismeret Tenger]

Rob, 

The BOR already have the option to put any kind of airfoils on its surface,, not just circle, see the XSec tab attached.  

On another note, can you elaborate on the Mode on the Design tab?  I am not getting what the Upper and Lower means in that Mode context and I could not find documentation about them and could not decipher the shape they produced.

.

[Rob McDonald]

The circle I'm speaking of is the cross section formed in the Y-Z plane.  For a BOR, these are always circles.  For the shape you describe, they would be non-circular.

BOR can work in two ways...

When making a toroidal body, it takes a closed curve and revolves it around the X-axis.

When making a body without a hole in the middle, it takes a curve segment and revolves it around the X-axis to make a body.

Since all the XSecCurves in OpenVSP are closed curves, when you do the second kind of BOR, you must choose which part of the curve you want to revolve.  The top or bottom of the closed curve.

Imagine you want to revolve a cambered (say NACA 4412) airfoil.  Do you want to revolve the curved upper surface, or the nearly flat bottom surface?

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/9f0d871f-88de-4069-acbe-e6200a461c58n%40googlegroups.com.

[Brandon Litherland]

I just put a section on BoR on the Ground School website here: https://vspu.larc.nasa.gov/training-content/chapter-1-vspfundamentals/bodies-of-revolution/

Hopefully this is helpful.

[Ismeret Tenger]

Brandon,

It is very nice.  I wish I would had it a month ago. ;-)

[Ismeret Tenger]

Hi,

I am coming back to the PS question, that is if I have a coax rotor system - which is not a new thing - , the FOM in the case of unsteady rotor is calculated just for the front rotor but not for the trailing one.  Any comment on it why is it so?

Thanks ahead,

János

[Rob McDonald]

No idea...

I would suggest you run a case like that -- and then poke around in the files VSPAERO writes out.

It may be that VSPAERO is doing the right thing, but OpenVSP is parsing the data wrong before plotting it there.

First thing to do is figure out whether the problem is with VSPAERO (is it really writing out zeros) or OpenVSP -- we're messing up the parsing when there are multiple rotors.

Rob

[Ismeret Tenger]

Hi Rob,

I attach three .csv files.  When I open the NACS0012M00.csv in Numbers on my Mac I have FOM in two places, - as I would expect -, at row 333 and row 526.  I cannot decipher which one belongs to which rotors, but row 333 contains only zeros.  The "Upper rotor" is the front rotor and the "lower rotor" is the trailing one.  /Sorry for that confusion, it wants to be a vtol on the long run./  So if I am reading well, the FOM and only the FOM is not calculated for the trailing rotor.  All other. rotors related parameters are calculated and displayed.  For Groups I am not getting anything, but I do not worry because I do not have groups yet.

DegenGeom.rotor.1 has 0.0 for all FOM, so I guess the program calculates first for the trailing rotor.

Other question:  Right now I am spinning the rotors with 260 rpm.  When I do it with 320, the wake lines are coming to the from after the 7th step and shortly after they go chaotic. With the 35 unit diameter rotors the tip speed around 152m/s way below transonic.  Is there a built in limit for rpm, or it depends on the blades and their airfoil only?

Thanks ahead,

János

[Rob McDonald]

I've found the issue -- I think it is a problem with how OpenVSP is feeding rotor data to VSPAERO.  I think Justin may have already fixed this for the next version.  I'll let him chime in.

The code to calculate FOM is here.

Note that it refuses to calculate FOM if the thrust coefficient is negative.  For one of your rotors, the thrust coefficient is always negative.

If you move your rotors to be non co-axial (but change nothing else in your setup), do you get the same result?

If your second rotor appears to be generating positive thrust -- but the coefficient is coming out negative, then we may have something wrong in transferring the file between OpenVSP and VSPAERO.  Justin may have already fixed the issue.

However, if when moved, your second rotor switches from making negative thrust to positive thrust, then I think everything is behaving properly and you just have a lousy design for your second rotor.

The second rotor in a coaxial system needs a substantially different design from the first one.  Particularly if the separation between the rotors is significant.  

When you change RPM, are you still using the 'automatic' time step setup, or are you manually setting those things?  You will need to adjust them for a change in RPM.

In fact, it would not surprise me if you need to take manual control of those settings for your coaxial rotor system.  See if reducing dt and increasing the number of time steps helps with your rotors going chaotic.

Also, if these are in a hovering condition (no freestream axial flow) you might want to work with the hover ramp settings.  Sometimes that can help to initialize the flow to blow the wake downstream as the solution develops.

In any case, if your second rotor is producing negative thrust, you are going to have an ugly wake.  You need it producing positive thrust to blow the wake away.

Rob

[Ismeret Tenger]

Rob,

The two rotors by design are the same.  The only difference is that the trailing rotor is rotated with 60 degree, so when at the start of the analysis looking from the front, one can see 6  blades equidegree of 60 from each other.  Originally the front rotor is rotating clockwise and the trailing one is counterclockwise. They are 1 unit from each other in the X-direction.  The FOM - negative values for some reason -, is calculated only for the counterclockwise rotating rotor, that is for the trailing rotor.  

Now if I reverse the Rev parameter and make the front rotor rotating counterclockwise and the trailing one clockwise, than the FOM is calculated for the front rotor - again the values are negative, I expected positive ones.

In both cases the CT trust coefficient is negative for the rotor with zero FOM, so quite possible that the FOM is calculated RIGHT.  Now the question is why the clockwise rotating rotor CT is negative, independently from its position, that is being front or trailing ?

I am using the VT-15 airfoil.

I do the Auto Time Step for Num Revs 2.  RPM is 450 for both rotors.  Every rotor has 3 blades 120 degree from each other and the trailing rotor is rotated with 60 degree.

Yes, in Advanced Flow Conditions I set Vinf 450 and Vref to 450 and MachRef to 0.4 when I test for Mach0.4.  I know that Vinf 450 is supersonic, but when I tried with a most reasonable value, like 132, /Mach 0.4 in meter/sec/,  the wake lines became chaotic after the 8th timestep.

I attache again  two .csv files for the craft and the four DegenGeom files for the rotors. Someone might have a better eye than me..

[Ismeret Tenger]

Well, I changed everything to NoShow except the front rotor with clockwise rotation.  Run the analysis and get positive Ct and positive good FOM for the rotor.  

Changing nothing, just the direction of rotation, that is switched on Rev on the same rotor, and after the analysis, I get negative CT and zero FOM.  

So, looks to me that when Rev is in, the trust turns negative, which zeros out the FOM.

[Ismeret Tenger]

Looks like it is OK for non-cambered airfoils, like when prop has when added to a vehicle.  However with VR-15 airfoil - which is a non-symmetric cambered airfoil -, when I set Rev, the CT becomes negative and the FOM is zero.

I tested it out with a new vehicle having just a 3-blade rotor with everything as default except the diameter which I set to 4.  For the default airfoil combo I had positive CT, Rev set or not, and positive FOM.  When I changed just the airfoil on all three sections to VR-12 and Rev set, the CT became negative and the FOM zero.