OpenRocket and Sphereachute Chute Data discrepancy

[WizardOfBoz]

Hi. After purchasing a few Spherechutes I did a simulation to check my 2.2kg rocket's descent velocity. My original Topflight 36 inch chute was projected to hit 27fps and I was trying to get a bit less hot. To my dismay the Sphereachute 42" chute was projected to have a descent velocity of about 40fps!

Sphereachute uses a nominal size based upon the circumference of the half-spherical (hemisphere) of their chutes. They also give the actual (diametral) dimension which is the opening of the chute. The later is the same as, for example, what Fruity Chutes uses. Sphereachute reports a Cd of 0.75 for their hemispherical chute. Fruity and other use a Cd of 1.5. What gives?

I could bore you all with a lot of detail but what I found I believe is this.

In fitting parameters for the descent velocity equation to the velocity tables on the Sphereachute site, using actual (diametral) dimensions for diameter, I got a Cd of 2.12.
If I used instead the nominal (larger, circumferential) diameter I got a Cd of 0.88.
So one can use the smaller (diametral) diameter and the larger 2.19 Cd, or
One can use the larger (nominal, or circumferential) diameter with a Cd of 0.88
Either way, I can replicate the velocity predicted.

But OR uses the smaller diameter and the smaller Cd and the velocity predicted is nearly 100% faster than those given on the Sphereachute site. That is, the data for Spherachute needs to be changed in OR. As a first step, the Cd values could just be changed from 0.75 to 2.19. This approximates the chart.

How can this be achieved and how can I help?

 

[neil_w]

How can this be achieved and how can I help?

File an issue: https://github.com/openrocket/openrocket/issues

 

[Buckeye]

You beat this to death in your other thread.

The A in the denominator of defining Cd cancels out the A in the terminal velocity equation. Doesn't matter what A is, as long at it is consistent. Could be 1.0 billion square miles. Doesn't matter.

Cd and A must be specified together. Spherachutes states their Cd is 0.75, and chute size is specified by the circumferential diameter. Odd, but that is their prerogative, and their descent table works. OR has the diameter wrong. The diameter should be changed, not the CD quoted by spherachutes.

 

[JoePfeiffer]

You beat this to death in your other thread.

The A in the denominator of defining Cd cancels out the A in the terminal velocity equation. Doesn't matter what A is, as long at it is consistent. Could be 1.0 billion square miles. Doesn't matter.

Cd and A must be specified together. Spherachutes states their Cd is 0.75, and chute size is specified by the circumferential diameter. Odd, but that is their prerogative, and their descent table works. OR has the diameter wrong. The diameter should be changed, not the CD quoted by spherachutes.

Well, we have to change either the Cd or their stated diameter (which we also got from them).... but the one that does the least violence to the numbers they gave us is to change the diameter.

Need to think of a way to make it clear to a user who checks that when we say a chute's diameter is 42" and Sphereachutes says a 42" parachute has a diameter of 26.75" the data we're using is correct...

 

[JoePfeiffer]

How can this be achieved and how can I help?

How familiar are you with github? If you can file a pull request changing .../core/build/resources/main/datafiles/components/internal/Spherachutes_Parachutes.orc to use the correct values for diameter, it would be perfect. Also good would be to take @neil_w 's suggestion and file an issue. If you don't have any github experience, we can do it -- it sounds like for all their hemispherical parachutes the diameter in the chute name should be used as the diameter, not the "diameter" they quote in parentheses?

 

[WizardOfBoz]

I occasionally use github. I'll try to check out the .orc file. And then I suppose I'll make a merge request so that the work will be reviewed before being deployed in the release version?

 

[JoePfeiffer]

I occasionally use github. I'll try to check out the .orc file. And then I suppose I'll make a merge request so that the work will be reviewed before being deployed in the release version?

Exactly.

 

[Chuck Rogers]

The A in the denominator of defining Cd cancels out the A in the terminal velocity equation. Doesn't matter what A is, as long at it is consistent. Could be 1.0 billion square miles. Doesn't matter.

Cd and A must be specified together. Spherachutes states their Cd is 0.75, and chute size is specified by the circumferential diameter. Odd, but that is their prerogative, and their descent table works. OR has the diameter wrong. The diameter should be changed, not the CD quoted by spherachutes.

Buckeye wrote [for a parachute]:

<< Cd and A must be specified together. >>


I agree. From the RASAero II Users Manual, Page 82:

"Note that the diameter of the parachute is the diameter with the parachute laid flat on the ground. This is the way most model and high power rocket parachutes are measured, and is the reference area convention used to develop the parachute drag coefficient data used in the RASAero II software.

Note the default parachute drag coefficient (CD) of 1.33 is based on a study of high power rocket descent rates as a function of parachute size, but the User has the option of entering his own parachute CD based on descent rate flight data for the parachute being used."


The maximum descent velocity on the parachute can be used to get the parachute drag coefficient (CD), but I prefer to use the entire descent, the altitude versus time for the entire descent. Barometric altimeter flight data during the parachute descent is ideal for this.


For the analysis the parachute CD is varied until the descent time from apogee to the ground is matched, which typically provides a very good match of the altitude versus time during the parachute descent. From a study of parachute descents for high power rockets, it was determined that a typical value for the parachute CD should be 1.33, using the reference area definition above. In RASAero II the User is of course free to enter whatever parachute CD value they want, the 1.33 value just comes up as a default as a suggestion, it can be replaced with another user-entered value.


An example parachute descent is in the RASAero II Users Manual as part of an Example Rocket on Pages 117-129. The descent barometric altimeter flight data and the RASAero II Flight Simulation plot are presented below. The RASAero II Flight Simulation in the plots below uses the parachute CD of 1.33. From apogee to landing the parachute descent time based on the barometric altimeter flight data was 241 sec. Using the parachute CD of 1.33, the RASAero II Flight Simulation predicted parachute descent time is 218.71 sec, an error of -9.25% in the parachute descent time from apogee to landing.




Again, to measure inflight parachute CD data, I prefer to match the descent time, apogee to the landing. This typically provides a very good match to the barometric altimeter flight data for altitude versus time during the parachute descent, which is ultimately what you want to try to match.


A parachute CD of 1.33 sounds high? Remember, this is rocket in-flight parachute descent flight data. It is the rocket descending with the parachute on top, shock cord, the nose cone and payload section, another shock cord, and then the main rocket body; all descending in a line, all descending in a "train", all vertically orientated top to bottom. Technically this is the CD of the entire vertically orientated line of items, using the reference area of the parachute (the parachute reference area being defined above). The parachute is making most of the drag, but the drag of the other items during the vertical descent are also included in the CD.



Charles E. (Chuck) Rogers
Rogers Aeroscience

 

[WizardOfBoz]

I agree with what Chuck and buckeye say. Chuck, since you are aeroscience, would you check my work? If you read markdown I've posted the file elsewhere. When I'm at my computer ( and not having cocktails on the deck, responding with my phone) I'll upload the file.

 

[Chuck Rogers]

I agree with what Chuck and buckeye say. Chuck, since you are aeroscience, would you check my work? If you read markdown I've posted the file elsewhere. When I'm at my computer ( and not having cocktails on the deck, responding with my phone) I'll upload the file.

I'm more than happy to look at it. Try to have the data summarized, and provide web site links for the parachute data sources.

I'll also need the weight on the parachute during the parachute descent.


Charles E. (Chuck) Rogers

 

[mikec]

We have two threads going on this, which is at least 1 too many.

In my experience, if you just use Spherachute's stated diameter and a Cd of 0.75, you get something not too far from reality. As an example, a rocket with descent mass of 4.23# had a measured descent rate of 20.7 fps, and OR predicted 21.3 fps. Which suggests that a Spherachute is a little more efficient than a parasheet of equivalent flat diameter, but not by a huge amount.

"If it ain't broke don't fix it."

 

[WizardOfBoz]

@mikec one thread was started in recovery when OR gave me wildly different descent rates (like double) what I expected from the charts on Sphereachute's site.

A lot of the back and forth (and the markdown I'm attaching) was to figure out why. With help from you and others, we did that. Basically:
Nominal (larger) chute diameter + smaller Cd works
Diametral (smaller) chute diameter + larger Cd works.

OR has Diametral (smaller) chute diameter and smaller Cd. This doesn't work.

The thread on the software forum (this thread) is to figure out how best to correct OR so that its predictions are aligned with reality.

Right now I'm trying only to post on this forum to addres the OR issue.

So the steps I see are
1) An expert like you can review my markdown doc for correctness
2) If correct, we can let Julie at Spherachute know that we are correcting OR
3) We should decide whether to either a) change all the Spherachute diameters from diametral to nominal, or b) change all the Sphereachute hemispherical Cd values to 1.6 or 1.8 or ??? The 1.8 value seems to match their descent rate chart
4) Execute the change: check out the .ork file from github, make the changes, review the changes, and commit for the next revision.

 

[mikec]

Your attachment doesn't seem to have come through.

I tried filing an issue against the Spherachutes file on github but my request vanished into the ether (or maybe I did it incorrectly or it's still being reviewed or something, if so, sorry for any confusion.)

The easiest thing to do would be to change all of the diameters in the file to the larger flat diameters. That wouldn't exactly match the Spherachutes table, but it would be much closer than what one gets now.

 

[WizardOfBoz]

Your attachment doesn't seem to have come through.

I tried filing an issue against the Spherachutes file on github but my request vanished into the ether (or maybe I did it incorrectly or it's still being reviewed or something, if so, sorry for any confusion.)

The easiest thing to do would be to change all of the diameters in the file to the larger flat diameters. That wouldn't exactly match the Spherachutes table, but it would be much closer than what one gets now.

I tried a couple of times to attach my .md file and when I hit save it just deletes the attachment. I'll try zipping it.

There's two POVs here. Change the diameters to match the MFRs site, or change the cd to align with how other chutes are specified in OR. I suggested the latter but you and others with more experience like the former. I will defer to you on this point.

 

[WizardOfBoz]

Let's try a zip file.

 

[JoePfeiffer]

I tried a couple of times to attach my .md file and when I hit save it just deletes the attachment. I'll try zipping it.

There's two POVs here. Change the diameters to match the MFRs site, or change the cd to align with how other chutes are specified in OR. I suggested the latter but you and others with more experience like the former. I will defer to you on this point.

I think the best way forward is to change the diameters to the circumferential value, as this lets you use the Cd they specify and matches their part names on their web site. You're right that other manufacturers of true parachutes seem to use the diametral value, but this seems like it'll cause the least confusion for users.

 

[JoePfeiffer]

I tried filing an issue against the Spherachutes file on github but my request vanished into the ether (or maybe I did it incorrectly or it's still being reviewed or something, if so, sorry for any confusion.)

You're right, it seems to have vanished... no idea why, I haven't heard of people having this problem on github before...

 

[WizardOfBoz]

Mike and Joe, the point you make seems reasonable.

The drag/velocity equation uses cross-sectional area. For every type of chute we use an approximation. We say we have a circle but elliptical and hemi cross-sections have scalloped edges. Parasheets are.... Well, I don't know what shape they are. Richard Nakka talks about a shape equation. Is there a standard shape equation for parasheets? I also like the closer-to-actual diameter as it gives a more standard agreement with Reynold's number vs Cd correlationns.

My push for using diametral dimension is that this gives the closest approximation to actual cross section. It would seem to me that ideally for each type chute we should have

Nominal dimension. What you can measure (flat to flat on a parasheet, circumference on a hemi)
Conversion factor to a diameter that gives an accurate cross-section (for example 2/pi for hemis)
Effective Diameter. Gives a pretty accurate area
Cd for Effective Diameter. Given that now all the chutes have physically representative and accurate areas, we can compare chutes and chute efficiencies

So I can get:


Ok, now that I have a Reynold's number I'm happy enough. And I accept that having the same values as on the mfrs site probably means that folks will trust the measurement more. I'll download the file from github (I hope today) and take a look. I'll adjust the diameters...

PS In my day job I write math models of human disease. For the past 25 years I've tried to convince clinical research scientists and physicians that you can't curve-fit your way to predicting trials you haven't done. Or as Judea Pearl puts it ("The Book of Why" - recommended) "You can't predict counterfactuals using correlations". You need a causal model. This is why I try to get the diameters representing accurate physical areas. But at the end of the day, if you use the proper D/Cd pair, your model lands safely and without damage. No trial patient will die because we effed up the dose calc. So I'm good...

 

[mikec]

You're right, it seems to have vanished... no idea why, I haven't heard of people having this problem on github before...

Maybe associated with the big IT outage this weekend, I just tried it again and it worked.

[later] Forked, made changes and created pull request.

 

[Buckeye]

Need to think of a way to make it clear to a user who checks that when we say a chute's diameter is 42" and Sphereachutes says a 42" parachute has a diameter of 26.75" the data we're using is correct...

Perhaps change the name of the parameter in OR to "reference length."

 

[Neutronium95]

I just don't really simulate the parachute descent on Openrocket. I put in a parachute that's roughly the correct size, but all of my parachute selections are based off of vendor recommendations and simple descent rate calculators.