Altitude Prediction Gap Make Sense? - OR v RASAero II

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

MichiganJohn

Well-Known Member
TRF Supporter
Joined
Nov 16, 2020
Messages
57
Reaction score
41
Location
SE Michigan
Edit: This question might be best posed to folks with experience or knowledge flying over 40-50K feet.

I'm working on a two stage project - both stages are 75mm minimum diameter, using a 4-grain motor in the booster (M1297) and 6-grain in stage two (M685).

I built a single stage 75mm min diameter (M1350) last year and flew successfully at Airfest - I have good correlation between the OpenRocket and RASAero models from that project and the actual results (~20K altitude and ~1.9mach).

However, looking at the modelled altitude prediction for this two stage design there is a big difference between OR and RASAero - on the order of 55K vs 85K respectively (and max velocity ~2.1mach vs ~2.5mach) . From going through threads I know there's a methodology difference between RASAero, which calculates thrust at different altitudes (using nozzle exit diameter) versus OR which holds thrust constant, but 55K v 85K seems like a pretty big difference.

Initially I assumed my RASAero model had some sort of mistake (and it could) but I've spent quite a bit of time looking for errors, and thought it might be a good time to throw the question out to the forum as a sanity check - is this a glaring mistake in my model, and keep looking for errors? Or a reasonable difference based on higher altitude and the software methodology?

Also worth noting I'm not an engineer, just a guy who likes to build HPR and push each project a little further. Meaning I've spent a good amount of time learning and using RASAero over the last couple years, but I'm no expert on the software.

Thanks for any informed feedback!
 
Last edited:
Thanks and I take your point with referenced thread (ie. if you ask for help be prepared to share files). Maybe it's a fine nuance but I'm not looking for help with my models at this point, just whether the difference in results might be reasonable given the design conditions I described. If the answer is 'no' I'd like to do more diagnostic work on my own first.

I thought there might be a few folks with first hand experience or knowledge of flying over 40-50K feet that could weigh in (without having to trouble shoot using models) - I updated original post to reflect that. Apologies if the way I posed the question is bad form - was not intending to be offensive to anyone.
 
Last edited:
RasAeroII is better at simming rockets that are in the mach range than OR historically, at least thats what those who understand the ins and outs of the softwares have pointed out to me, RasAeroII looks deceptively simple but in reality its a pretty powerful sim-tool for the hobbyist. Flights over Mach I would put my money on RasAeroII being closer to correct than OR, under Mach I have found both to be reasonably close in results.
 
Mostly depends on the surface finish and turbulence settings. RASAero, at least the way they suggest you set it, is more pessimistic/realistic than OR.
 
Take your original sim for the M1350 where both agreed and swap for the 2 new motors one at a time in both and see that they both still agree. At least then you'll know the thrust curves being used by each agree.
As you won't post your sims here, you're on your own for finding any anomalies in the sims. Both would have to be physically modeled separately as you cannot import the RAS Aero model onto OpenRocket or vice versa so it's possible to have errors between the 2 models you've created.
Check your surface finishes for all components match. Once you've done all that, trust RASAero..... @Chuck Rogers @JoePfeiffer The gods have been summoned.... :)
Good luck
 
Take your original sim for the M1350 where both agreed and swap for the 2 new motors one at a time in both and see that they both still agree. At least then you'll know the thrust curves being used by each agree.
As you won't post your sims here, you're on your own for finding any anomalies in the sims. Both would have to be physically modeled separately as you cannot import the RAS Aero model onto OpenRocket or vice versa so it's possible to have errors between the 2 models you've created.
Check your surface finishes for all components match.

Thank you. I'll cross-reference the thrust curve files, I haven't done that yet.

The version of OpenRocket I use allows you to export directly into CDX1 format, which I did - and confirmed that the geometry, weights, and CG locations transferred correctly. After reading through the MESOS RASAero II thread (https://www.rocketryforum.com/threads/mesos-flight-to-293k-ft-rasaero-ii-prediction-290k-ft.176970/ ) I'm also using turbulent flow and smooth paint assumptions.

The RASAero model's sensitivity to the 'nozzle exit diameter' dimension is significant - when I use 1.87 inch as the nozzle exit diameter of an AeroTech 75mm commercial nozzle, max alt is calculated at 86K - if I leave that entry blank or use zero, max alt is 63K (and OpenRocket is 57K).

Chuck R explained in the MESOS thread that RASAero II varies thrust calculation with altitude (using the nozzle exit diameter dimension), whereas OpenRocket does not. I 'assumed' that a majority of the difference in predicted altitude between the two was associated with thrust calculation methodology, and that higher altitude flights would be more affected than lower altitude flights. But that much variance still seemed like a lot... therefore my 'sanity check' question.

Maybe a different way to frame my concern is: Sims I've done in the past have always been 'fairly' close between OR and RAero. But I haven't modelled a flight beyond 30K before, and was surprised how different the results were OR vs RAero. Maybe most of the variance is explained by thrust calculation methods (after all they are within 10% if nozzle exit diameter is left blank in RAero). But that difference when using nozzle exit diameter is huge, and if that method is most accurate, the OR prediction is way off - and I'm surprised about that - if you were relying on OR for that sim you would be off the mark by roughly 50%.

My RASAero II file is attached - the simulation I'm referencing is number two (M685, M1297).
 

Attachments

  • Project Y - RASAero II.CDX1
    6.7 KB · Views: 0
Last edited:
@MichiganJohn --

I imported the RASAero.CDX1 file into OR which raised a couple Qs ...

Q1: As @Buckeye said, RASAero stores Launch Masses in the Sim Blocks. What are the real DRY masses of the booster and sustainer ?

Q2: The fins on the sustainer overhang the tail by one-inch ... should that be negative 1 inch ?

I changed the materials to Fiberglass and removed the mass and CG overrides and reentered your site environment and motor selection:
Screenshot_20240318_085745.png

I set the ignition delay to the same 8-sec as I found in the original .CDX1 and ran the sim.
sim-m1297-to-m685.png

Zoom in on Thrust Phase:
sim-m1297-to-m685-zoom.png
I believe the 'new' masses may be too low but it looks like a start ...

HTH

-- kjh
 

Attachments

  • Project-Y-RASAero-II-messed-with.ork
    533 KB · Views: 0
@JoePfeiffer --

if the launch mass of @MichiganJohn's stack is really something like 3 kg then ...

Could there be an CDX1 import bug in OR for multi-stage rockets ?

There are two sims in John's original .CDX1 file:

These are the launch masses from the XML-ish file:
Code:
[konrad@kjhlt7 ~]$ grep -e Simulation -e LaunchWt  Project-Y-RASAero-II.CDX1
  <SimulationList>
    <Simulation>
      <SustainerLaunchWt>18.04</SustainerLaunchWt>
      <Booster1LaunchWt>40.42</Booster1LaunchWt>
      <Booster2LaunchWt>0</Booster2LaunchWt>
    </Simulation>
    <Simulation>
      <SustainerLaunchWt>22.57</SustainerLaunchWt>
      <Booster1LaunchWt>40.42</Booster1LaunchWt>
      <Booster2LaunchWt>0</Booster2LaunchWt>
    </Simulation>
  </SimulationList>

I don't have a copy of RASAero any more, but it looks like the BoosterLaunchWt includes the mass of the Sustainer.

If I subtract the Sustainer Mass from the Booster Mass I get a mass for the stack similar to when I removed mass and CG overrides and let OR calculate masses from densities of the materials I chose ...

Could OR be mis-calculating the mass overrides of the Booster and Sustainer when it imports a multi-stage rocket ?

-- kjh

EDIT: This is a screenshot of the originally imported .CDX1 File.

Note the Dry Mass and Launch Mass:

Screenshot_20240318_093629.png
 
Last edited:
Plot the thrust during the simulation (not just the .eng files) to see how much RASAero is manipulating the thrust at altitude. Also plot drag and compare the 2 software.
Thanks @Buckeye - appreciate your suggestion - I'll dig in and break down thrust and drag to compare, as a troubleshooting approach. As I'm finalizing my models, if I still can't account for the variation I'll have good data to summarize and share back out for another round of feedback.

@MichiganJohn --

I imported the RASAero.CDX1 file into OR which raised a couple Qs ...

Q1: As @Buckeye said, RASAero stores Launch Masses in the Sim Blocks. What are the real DRY masses of the booster and sustainer ?

Q2: The fins on the sustainer overhang the tail by one-inch ... should that be negative 1 inch ?

I changed the materials to Fiberglass and removed the mass and CG overrides and reentered your site environment and motor selection:

Thanks @kjhambrick for the backward solve in OR. I actually went the other direction (exported my OR design into CDX1 format), but it's interesting that the altitude is very similar with your new OR version compared to my RASAero - I'll need to double-confirm that the masses transferred correctly into RASAero.

The dry mass estimates I'm currently using in OR are: booster 122oz, sustainer 125oz (using my single stage 75mm min diameter project as a benchmark).

And the sustainer fins overhang by 1 inch to aid in stability given that the upper stage is nested and the motor overrhangs by 3.5inches to fit into the Interstage Coupler. I want to keep fin height to about one body diameter while providing a minimum of 2.0 cals of stability - moving them back an inch was helpful to achieve that, and I don't expect detrimental to durability. I may be able to ultimately move them further forward as mass and CG is finalized.


Thanks both again for your thought and responses.
 
MichiganJohn:


<< I'm working on a two stage project - both stages are 75mm minimum diameter, using a 4-grain motor in the booster (M1297) and 6-grain in stage two (M685).

I built a single stage 75mm min diameter (M1350) last year and flew successfully at Airfest - I have good correlation between the OpenRocket and RASAero models from that project and the actual results (~20K altitude and ~1.9mach). >>


Compare the thrust curves for each stage in the Flight Simulation output from each program. In particular compare the thrust curves for the second stage.


Both programs start with the ThrustCurve.org thrust curve. But RASAero varies thrust with altitude by assuming the rasp.eng data from ThrustCurve.org is a sea level thrust curve, and then uses the Nozzle Exit Area (based on the Nozzle Exit Diameter input) to vary thrust with altitude. This is why it is important to include the Nozzle Exit Diameter when running RASAero, and to input an accurate value for the Nozzle Exit Diameter. In RASAero the Nozzle Exit Diameter input is not just used for the Power-On CD, it is also used to vary thrust with altitude.


Note that you've moved from a single-stage flight to a two-stage flight. This variation of thrust with altitude effect can be especially important for a second stage, in particular for a delay-staged second stage.


An example of the effect of the variation of thrust with altitude is shown below for a ground-launched single-stage long burn N motor, an N1048. The rasp.eng thrust curve is shown (Thrust, TC), and the thrust curve from the RASAero Flight Simulation (Thrust, RA) which includes variation of thrust with altitude is also shown.


1710807748038.jpeg


This is for a ground-launched single-stage long burn rocket motor. Imagine this effect for a delay-staged second stage.


Optimizing this effect by optimizing the second stage expansion ratio gained Kip Daugirdas 10% in altitude, to get 90% of the way to the Karman Line (Space).


After plotting out the different thrust curves, then plot out the Drag Coefficients (CD's) for the two programs. RASAero has more accurate CD models.


As was noted, also check the weights. RASAero uses an inputted Loaded Weight for Stage-1 and Stage-2 combined (the Lift-Off Weight), and then an inputted Loaded Weight for Stage-2.



Charles E. (Chuck) Rogers
Rogers Aeroscience
 
Last edited:
This is for a ground-launched single-stage long burn rocket motor. Imagine this effect for a delay-staged second stage.
For an ultra extreme example: Karman Line N2O Hybrid/single stage/37s burn - 340kft with a 4" exit / 550kft with a 6" exit. Same everything other than exit as per simmed in RASAero II.

TP

ps: of course, there are limits to how far you can push this with flow separation potential, but if the nozzle's exit is stout enough, you can potentially push it pretty hard.
 
Last edited:
It's certainly possible. I'll transcribe your post to github and open an issue.
One thing @JoePfeiffer ...

I said something like ... if the launch mass of the stack is something like 3 Kg ...

I should have said: if the DRY mass of the stack is something like 3 Kg ...

Sorry about the confustion.

This might be helpful for the developer:

I imported several single stage CDX1 files into OR and in every case, the "stage override" masses in OR do include the motor masses from the simulation sections of the .CDX1 file.

For example, these are relevant rows from an example EZI-65 file in the RASAero distribution:
Code:
/home/konrad/ezi65-1.cdx1:  <SimulationList>
/home/konrad/ezi65-1.cdx1:    <Simulation>
/home/konrad/ezi65-1.cdx1:      <SustainerEngine>J450ST  (AMW)</SustainerEngine>
/home/konrad/ezi65-1.cdx1:      <SustainerLaunchWt>10.06</SustainerLaunchWt>
/home/konrad/ezi65-1.cdx1:      <SustainerCG>59</SustainerCG>
/home/konrad/ezi65-1.cdx1:      <Booster1LaunchWt>0</Booster1LaunchWt>
/home/konrad/ezi65-1.cdx1:      <Booster1CG>0</Booster1CG>
/home/konrad/ezi65-1.cdx1:      <Booster2LaunchWt>0</Booster2LaunchWt>
/home/konrad/ezi65-1.cdx1:      <Booster2CG>0</Booster2CG>
/home/konrad/ezi65-1.cdx1:    </Simulation>
/home/konrad/ezi65-1.cdx1:  </SimulationList>

On import, there is a mass override for the sustainer and the "Mass with no Motors" in OR is listed as 4563 grams which is simply 10.06 lbs converted to grams.

I believe the mass needs to be adjusted down by the 'launch mass' of the AMW J450ST ( 1196 grams ) which is easy to do as long as the motor in the RASAero sim is also included in the OR RASP.ENG datafile.

However, maybe not so simple is the CG override ...

OR also sets a CG override = 59 for the Sustainer which is the CG of the rocket + motor from the RASAero sim data above.

The CG override for the "Mass with no Motors" will also need to be adjusted by the Mass and geometry of the motor wrt the launch mass, geometry and CG of the rocket including the motor ...

HTH and thanks Joe !

-- kjh
 
Personally, I don't expect a translator to do anything more than import/export the geometry. No masses, no materials, no simulation settings, etc. All these things need to be double checked in the new environment. I assume the OP did this correctly, and the software comparison boils down to thrust and drag computed during run time.
 
Personally, I don't expect a translator to do anything more than import/export the geometry. No masses, no materials, no simulation settings, etc. All these things need to be double checked in the new environment. I assume the OP did this correctly, and the software comparison boils down to thrust and drag computed during run time.
I agree 100% @Buckeye ...

However, since OR sets a Mass and CG override for each Stage, I would assume that they're 'close'.

I the case of @MichiganJohn's 2-stage M-to-M rocket with a high propellant mass fraction, the masses and CG's of the stack were causing confusion.

If it can't be cleaned up, it might be better to write something in the Comments Tab and completely clear the Mass and CG overrides in OR.

-- kjh
 
Compare the thrust curves for each stage in the Flight Simulation output from each program. In particular compare the thrust curves for the second stage.

Both programs start with the ThrustCurve.org thrust curve. But RASAero varies thrust with altitude by assuming the rasp.eng data from ThrustCurve.org is a sea level thrust curve, and then uses the Nozzle Exit Area (based on the Nozzle Exit Diameter input) to vary thrust with altitude. This is why it is important to include the Nozzle Exit Diameter when running RASAero, and to input an accurate value for the Nozzle Exit Diameter. In RASAero the Nozzle Exit Diameter input is not just used for the Power-On CD, it is also used to vary thrust with altitude.

Note that you've moved from a single-stage flight to a two-stage flight. This variation of thrust with altitude effect can be especially important for a second stage, in particular for a delay-staged second stage.

An example of the effect of the variation of thrust with altitude is shown below for a ground-launched single-stage long burn N motor, an N1048. The rasp.eng thrust curve is shown (Thrust, TC), and the thrust curve from the RASAero Flight Simulation (Thrust, RA) which includes variation of thrust with altitude is also shown.

This is for a ground-launched single-stage long burn rocket motor. Imagine this effect for a delay-staged second stage.

Optimizing this effect by optimizing the second stage expansion ratio gained Kip Daugirdas 10% in altitude, to get 90% of the way to the Karman Line (Space).

After plotting out the different thrust curves, then plot out the Drag Coefficients (CD's) for the two programs. RASAero has more accurate CD models.

Charles E. (Chuck) Rogers
Rogers Aeroscience
Thank you Chuck, this is exactly what I wanted to understand better. I appreciate your detailed response and will explore further via your suggestions. I haven't studied effect of expansion ratio, etc. yet - new things to learn. Thank you.
 
Last edited:
Back
Top